微服务和DDD到底有什么关系呢？

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

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

微服务的缺陷

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

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

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

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

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

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

DDD功用

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

• 功能纬度

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

• 工程纬度

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

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

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

image

拆分案例

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

关于领域

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

• 商品子域

• 订单子域

• 库存子域等等。

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

划分系统内部架构边界

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

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

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

image

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

边界清晰的好处

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

• 资源倾斜
• 使用弹力设计模式：比如重试，熔断，降级
• 使用特殊技术：比如Go语言
• 具备独立代码库：有独立团队和运维人员，和A和B的运行期做到隔离不互相影响

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

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

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

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

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

• 聚合根用来保证内部实体规则的正确性和数据的一致性
• 外部对象只能通过ID来引用聚合根，不能引用聚合根内部的实体
• 聚合根之间不能共享一个数据库事务，它们之间的数据一致性需要通过最终的一致性来保障

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

1、聚合根、实体、值对象的区别？
从标识的角度：

聚合根具有全局的唯一标识，而实体只有在聚合内部有唯一的本地标识，值对象没有唯一标识，不存在这个值对象或那个值对象的说法；

从是否只读的角度：

聚合根除了唯一标识外，其他所有状态信息都理论上可变；实体是可变的；值对象是只读的；

从生命周期的角度：

聚合根有独立的生命周期，实体的生命周期从属于其所属的聚合，实体完全由其所属的聚合根负责管理维护；值对象无生命周期可言，因为只是一个值；

2、聚合根、实体、值对象对象之间如何建立关联？
聚合根到聚合根：通过ID关联；

聚合根到其内部的实体，直接对象引用；

聚合根到值对象，直接对象引用；

实体对其他对象的引用规则：1）能引用其所属聚合内的聚合根、实体、值对象；2）能引用外部聚合根，但推荐以ID的方式关联，另外也可以关联某个外部聚合内的实体，但必须是ID关联，否则就出现同一个实体的引用被两个聚合根持有，这是不允许的，一个实体的引用只能被其所属的聚合根持有；

值对象对其他对象的引用规则：只需确保值对象是只读的即可，推荐值对象的所有属性都尽量是值对象；

3、如何识别聚合与聚合根？
明确含义：一个Bounded Context（界定的上下文）可能包含多个聚合，每个聚合都有一个根实体，叫做聚合根；

识别顺序：先找出哪些实体可能是聚合根，再逐个分析每个聚合根的边界，即该聚合根应该聚合哪些实体或值对象；最后再划分Bounded Context；

聚合边界确定法则：根据不变性约束规则（Invariant）。不变性规则有两类：1）聚合边界内必须具有哪些信息，如果没有这些信息就不能称为一个有效的聚合；2）聚合内的某些对象的状态必须满足某个业务规则；

1.一个聚合只有一个聚合根，聚合根是可以独立存在的，聚合中其他实体或值对象依赖与聚合根。

2.只有聚合根才能被外部访问到，聚合根维护聚合的内部一致性。