点击上方蓝色“
石杉的架构笔记”，选择“设为星标”
回复“PDF”获取独家整理的学习资料！
记得之前在规划和设计微服务架构的时候，张队长给了我一个至今依然记忆深刻的提示：『你的设计蓝图里为什么没有看到DDD的影子呢？』
随着对充血模型的领域认知的加深，我越加感
觉到DDD的重要性。
于是网上一顿海找，并做了学习笔记。
DDD内容繁多，个人浅见，它不同于传统贫血的最核心的一点就是把原先传统的贫血模型里的业务逻辑层拎出来，融入到Domain层，这样面对复杂业务的规模化变更，我们只需要专注于Domain即可。
回到主题，我们要了解的是微服务和 DDD 到底有什么关系呢？
因为在互联网时代，软件所面临的问题域比以往要复杂得多，这种复杂性来源于不断扩展的问题域自身，也来源于创新变化，以及这种规模性增长所带来的挑战。
然而一个人一个团队，他对复杂的事物的认知是有极限的，面对这种复杂问题唯一的方法就是分而治之。分主要考虑的是如何去分；治意味着分出来的每一个部分要能够独立的运行，能够互相的协作，完成整体的目标，能够一来应对外部变化所带来的冲击。
微服务架构在分和治两个方面都给出了很好的理论指导和最佳实践，那微服务是不是解决复杂问题的银弹呢？其实不然，很多团队在应用了微服务架构来构建他们的系统以后，发现并没有完全解决这种复杂性问题，甚至还带来了一些其他的问题。
-
服务并没有解决复杂系统如何应对需求变化这个问题，甚至还加剧了这个问题。
-
当一个需求变化了，需要花大量的精力去识别这个变化影响到了哪些微服务，这些服务的多个团队之间，需要通过无休止的扯皮去决定哪个服务多一些，哪些服务少改一些。
-
-
即便如此呢，开发团队依然不放心，还要通过一系列的开关控制，小心翼翼的去做切流，去做灰度发布。
从业务层面来看，微服务架构没有避免这种散弹式的修改。甚至反而加重了他，这是为什么呢？一个重要的原因是微服务架构在分的这个纬度考虑的并不全面。
当我们去做拆分这种工作的时候
，需要考虑哪些维度呢？我觉得我们至少要考虑三个维度：
微服务对第2个给出了很好的指导，对第3个也给出了一些建议。但是，对第1个功能纬度只给出来非常有限的指导，就是为什么随着微服务的流行，领域驱动设计(DDD)又被重新重视起来的原因。
DDD弥补了微服务在功能划分方面没有给出很好指导的缺陷。所以他们在面对复杂问题和构建系统时候是一种互补的关系，在系统拆分的时候可以很好的协作。
只是他们看待系统拆分这个角度是不同的。
微服务当中的服务所关注的范围正是DDD所推崇的六边形架构中的领域层。
关于领域
我们称企业的业务范围和在这个范围里进行的活动为领域，和软件系统无关。领域会分成多个子域，比如我们一个电商系统，会有：
在不同的子域里，不同的概念有不同的含义。所以我们在进行领域建模的时候，必须要有一个明确的领域边界，也就是DDD里称做的限界上下文，它是系统内部的一个架构边界，决定了这个系统架构。
划分系统内部架构边界
架构简洁之道这本书里边就说过：『系统架构是由系统的内部架构边界以及边界之间的依赖关系所决定的，与系统中各个组件之间的通信和调用的方式是无关的』。我们常说的微服务的服务调用本身只是一种比函数调用方式成本稍高的，分割应用程序行为的一种形式，系统架构无关。
所以，复杂系统划分的第一重要的是要划分内部的架构边界，即划分清楚这个上下文，以及明确他们之间的关系，这对应于我们之前说的功能的维度。这正是DDD用武之处。其次我们才考虑基于非功能的维度如何划分，这是微服务能够发挥其优势的地方。
举个例子，我们把系统分成ABC三个个上下文，三个上下文的代码可以在一个部署单元里运行，通过进程内调用来完成操作，这就是典型的单体架构：
我们也可以各自在一个独立的部署单元里运行，通过远程调用来完成操作，这就是现在流行的微服务架构。
边界清晰的好处
