为何在作微服务设计的时候须要DDD？

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

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

　　回到主题，咱们要了解的是微服务和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来引用聚合根，不能引用聚合根内部的实体
• 聚合根之间不能共享一个数据库事务，它们之间的数据一致性须要经过最终的一致性来保障

　　有了聚合根，基于这些约束，将来能够根据须要把聚合根升级为上下文，甚至拆分红微服务都是比较容易的。

　　另外想要知道如何合理的拆分微服务，能够参考个人另一篇文章《微服务划分的姿式》，今天就给你介绍到这儿，但愿对你有所启发。