记得之前在规划和设计微服务架构的时候，张队长给了我一个至今依然记忆深刻的提示：『你的设计蓝图里为什么没有看到DDD的影子呢？』

随着对充血模型的领域认知的加深，我越加感觉到DDD的重要性。但是DDD内容繁多，是不是要深入去了解呢，我觉得不必入坑太深，个人浅见，它最核心的一点就是针对贫血模型的不足而设计，把原先传统的贫血模型里的业务逻辑层拎出来，融入到Domain层，这样面对复杂业务的规模化变更，我们只需要专注于Domain即可。

　　                        https://www.cnblogs.com/jackyfei/p/12089123.html

       回到主题，我们要了解的是微服务和DDD到底有什么关系呢？

　　因为在互联网时代，软件所面临的问题域比以往要复杂得多，这种复杂性来源于不断扩展的问题域自身，也来源于创新变化，以及这种规模性增长所带来的挑战。

　　然而一个人一个团队，他对复杂的事物的认知是有极限的，面对这种复杂问题唯一的方法就是分而治之。分主要考虑的是如何去分；治意味着分出来的每一个部分要能够独立的运行，能够互相的协作，完成整体的目标，能够一来应对外部变化所带来的冲击。

微服务的缺陷

      微服务架构在分和治两个方面都给出了很好的理论指导和最佳实践，那微服务是不是解决复杂问题的银弹呢？其实不然，很多团队在应用了微服务架构来构建他们的系统以后，发现并没有完全解决这种复杂性问题，甚至还带来了一些其他的问题。比如:

• 服务并没有解决复杂系统如何应对需求变化这个问题，甚至还加剧了这个问题。

• 当一个需求变化了，需要花大量的精力去识别这个变化影响到了哪些微服务，这些服务的多个团队之间，需要通过无休止的扯皮去决定哪个服务多一些，哪些服务少改一些。

• 然后测试团队还需要做昂贵的这种联调测试

• 即便如此呢，开发团队依然不放心，还要通过一系列的开关控制，小心翼翼的去做切流，去做灰度发布。

      从业务层面来看，微服务架构没有避免这种散弹式的修改。甚至反而加重了他，这是为什么呢？一个重要的原因是微服务架构在分的这个纬度考虑的并不全面。

DDD功用

      当我们去做分的这种工作的时候，具体拆分详见我的另外一篇文章《微服务的拆分姿势》，需要考虑哪些维度呢？我觉得我们至少要考虑三个维度：

• 功能纬度

• 质量纬度，比如性能，可用性

• 工程纬度

      微服务对第2个给出了很好的指导，对第3个也给出了一些建议。但是，对第1个功能纬度只给出来非常有限的指导，就是为什么随着微服务的流行，领域驱动设计(DDD)又被重新重视起来的原因。

      DDD弥补了微服务在功能划分方面没有给出很好指导的缺陷。所以他们在面对复杂问题和构建系统时候是一种互补的关系，在系统拆分的时候可以很好的协作。

      只是他们看待系统拆分这个角度是不同的。微服务当中的服务所关注的范围正是DDD所推崇的六边形架构中的领域层。

拆分案例

   接下来结合DDD和微服务来拆分一个复杂系统。

关于领域

      我们称企业的业务范围和在这个范围里进行的活动为领域，和软件系统无关。领域会分成多个子域，比如我们一个电商系统，会有：

• 商品子域

• 订单子域

• 库存子域等等。

      在不同的子域里，不同的概念有不同的含义。所以我们在进行领域建模的时候，必须要有一个明确的领域边界，也就是DDD里称做的限界上下文，它是系统内部的一个架构边界，决定了这个系统架构。

划分系统内部架构边界

      架构简洁之道这本书里边就说过：『系统架构是由系统的内部架构边界以及边界之间的依赖关系所决定的，与系统中各个组件之间的通信和调用的方式是无关的』。我们常说的微服务的服务调用本身只是一种比函数调用方式成本稍高的，分割应用程序行为的一种形式，系统架构无关。

      所以，复杂系统划分的第一重要的是要划分内部的架构边界，即划分清楚这个上下文，以及明确他们之间的关系，这对应于我们之前说的功能的维度。这正是DDD用武之处。其次我们才考虑基于非功能的维度如何划分，这是微服务能够发挥其优势的地方。

　　举个例子，我们把系统分成ABC三个个上下文，三个上下文的代码可以在一个部署单元里运行，通过进程内调用来完成操作，这就是典型的单体架构；

　　也可以各自在一个独立的部署单元里运行，通过远程调用来完成操作，这就是现在流行的微服务架构。

边界清晰的好处

　　我们更多的是两种架构模式的一个混合，比如A和B一起是一个部署单元，C是另外一个独立的部署单元，这种情况往往是因为C非常重要，他并发的访问量非常大，或者它的需求变更比较频繁。将C拆分出来的有以下几个好处:

• 资源倾斜

• 使用弹力设计模式：比如重试，熔断，降级

• 使用特殊技术：比如Go语言

• 具备独立代码库：有独立团队和运维人员，和A和B的运行期做到隔离不互相影响

　　这四点正是服务架构所关注的，它是基于非功能纬度的视角来看待拆分这件事情的，他关注的不是系统架构的逻辑边界，更多的关注的是应用程序行为的分隔。

　　那为什么不把A和B都拆成一个独立的部署单元？

　　这会带来更多的好处，也会带来额外的成本，架构应该是可以演进的，在业务发展的早期，应该关注系统架构的逻辑边界，保持逻辑边界的清晰和关系的正确，随着业务量的增加，逐步在做拆分，这是组合应用DDD和微服务架构带来的最大的好处。

　　在单体架构中，保持架构逻辑边界不被突破是有一定难度。如果逻辑边界不清晰，在需要服务器拆分的时候，就未必能拆得出来了。另外没有人一下子就可以把逻辑边界定义正确，即使这个上下文定义的不太正确，在DDD聚合根这个概念可以保障我们能够演进出更适合的上下文。

　　DDD界限上下文内部通过实体和值对象来对领域概念进行建模，一组实体和值子对象归属于一个聚合根。那按DDD要求

• 聚合根用来保证内部实体规则的正确性和数据的一致性

• 外部对象只能通过ID来引用聚合根，不能引用聚合根内部的实体

• 聚合根之间不能共享一个数据库事务，它们之间的数据一致性需要通过最终的一致性来保障

　　有了聚合根，基于这些约束，未来可以根据需要把聚合根升级为上下文，甚至拆分成微服务都是比较容易的。

注意：本文归作者所有，未经作者允许，不得转载