关于领域驱动设计 DDD 中聚合设计的一些思考

Question

包含了一篇关于介绍如何有效的设计聚合的一些原则，共 3 个 pdf 文件。该文章中指出了以下几个聚合设计的原则，文章地址： http://dddcommunity.org/library/vernon_2011/

1. 聚合是用来封装真正的不变性，而不是简单的将对象组合在一起；
2. 聚合应尽量设计的小；
3. 聚合之间的关联通过 ID，而不是对象引用；
4. 聚合内强一致性，聚合之间最终一致性；

上面这几条原则，作者通过一个例子来逐步阐述。下面我按照我的理解对每个原则做一个简单的描述。

聚合是用来封装真正的不变性，而不是简单的将对象组合在一起

这个原则，就是强调聚合的真正用途除了封装我们本身所关心的信息外，最主要的目的是为了封装业务规则，保证数据的一致性。在我看来，这一点是设计聚合时最重要和最需要考虑的点；当我们在设计聚合时，要多想想当前聚合封装了哪些业务规则，实现了哪些数据一致性。所谓的业务规则是指，比如一个银行账号的余额不能小于 0，订单中的订单明细的个数不能为 0，订单中不能出现两个明细对应的商品 ID 相同，订单明细中的商品信息必须合法，商品的名称不能为空，回复被创建时必须要传入被回复的帖子（因为没有帖子的回复不是一个合法的回复），等；

聚合应尽量设计的小

这个原则，更多的是从技术的角度去考虑的。作者通过一个例子来说明，该例子中，一开始聚合设计的很大，包含了很多实体，但是后来发现因为该聚合包含的东西过多，导致多人操作时并发冲突严重，导致系统可用性变差；后来开发团队将原来的大聚合拆分为多个小聚合，当然，拆分为小聚合后，原来大聚合内维护的业务规则同样在多个小聚合上有所体现。

所以实现了既能解决并发冲突的问题，也能保证让聚合来封装业务规则，实现模型级别的数据一致性；另外，回复中的一位道友 殇、凌枫 提到，聚合设计的小还有一个好处，就是：业务决定聚合，业务改变聚合。聚合设计的小除了可以降低并发冲突的可能性之外，同样减少了业务改变的时候，聚合的拆分个数，降低了聚合大幅重构（拆分）的可能性，从而能让我们的领域模型更能适应业务的变化。

聚合之间通过 ID 关联

这个原则，是考虑到，其实聚合之间无需通过对象引用的方式来关联；

1. 首先通过引用关联，会导致聚合的边界不够清晰，如果通过 ID 关联，由于 ID 是值对象，且值对象正好是用来表达状态的；所以，可以让聚合内只包含只属于自己的实体或值对象，那这样每个聚合的边界就很清晰；每个聚合，关心的是自己有什么信息，自己封装了什么业务规则，自己实现了哪些数据一致性；
2. 如果通过引用关联，那需要实现 LazyLoad 的效果，否则当我们加载一个聚合的时候，就会把其关联的其他聚合也一起加载，而实际上我们有时在加载一个聚合时，不需要用到关联的那些聚合，所以在这种时候，就给性能带来一定影响，不过幸好我们现在的 ORM 都支持 LazyLoad，所以这点问题相对不是很大；
3. 你可能会问，聚合之间如果通过对象引用来关联，那聚合之间的交互就比较方便，因为我可以方便的直接拿到关联的聚合的引用；是的，这点是没错，但是如果聚合之间要交互，在经典 DDD 的架构下，一般可以通过两种方式解决：1）如果 A 聚合的某个方法需要依赖于 B 聚合对象，则我们可以将 B 聚合对象以参数的方式传递给 A 聚合，这样 A 对 B 没有属性上的关联，而只是参数上的依赖；一般当一个聚合需要直接访问另一个聚合的情况往往是在职责上表明 A 聚合需要通知 B 聚合做什么事情或者想从 B 聚合获取什么信息以便 A 聚合自己可以实现某种业务逻辑；2）如果两个聚合之间需要交互，但是这两个聚合本身只需要关注自己的那部分逻辑即可，典型的例子就是银行转账，在经典 DDD 下，我们一般会设计一个转账的领域服务，来协调源账号和目标账号之间的转入和转出，但源账号和目标账号本身只需要关注自己的转入或转出逻辑即可。这种情况下，源账号和目标账号两个聚合实例不需要相互关联引用，只需要引入领域服务来协调跨聚合的逻辑即可；
4. 如果一个聚合单单保存另外的聚合的 ID 还不够，那是否就需要引用另外的聚合了呢？也不必，此时我们可以将当前聚合所需要的外部聚合的信息封装为值对象，然后自己聚合该值对象即可。比如经典的订单的例子就是，订单聚合了一些订单明细，每个订单明细包含了商品 ID、商品名称、商品价格这三个来自商品聚合的信息；此时我们可以设计一个 ProductInfo 的值对象来包含这些信息，然后订单明细持有该 ProductInfo 值对象即可；实际上，这里的 ProductInfo 所包含的商品信息是在订单生成时对商品信息的状态的冗余，订单生成后，即便商品的价格变了，那订单明细中包含的 ProductInfo 信息也不会变，因为这个信息已经完全是订单聚合内部的东西了，也就是说和商品聚合无关了。
5. 实际上通过 ID 关联，也是达到设计小聚合的目标的一种方式；

聚合内强一致性，聚合之间最终一致性

这个原则主要的背景是：如果用 CQRS+Event Sourcing 的架构来实现 DDD，那聚合之间因为通过 Domain Event（领域事件）来实现交互了，所以同样也不需要聚合与聚合之间的对象引用，同时也不需要领域服务了，因为领域服务已经被 Process（流程聚合根）和 Process Manager（流程管理器，无状态）所替代。流程聚合根，负责封装流程的当前状态以及流程下一步该怎么走的逻辑，包括流程遇到异常时的回滚处理逻辑；流程管理器，无状态。负责协调流程中各个参与者聚合根之间的消息交互，它会接受聚合根产生的 domain event，然后发送 command。

另外一方面，由于 CQRS 的引入，使得我们的 domain 只需要处理业务逻辑，而不需要应付查询相关的需求了，各种查询需求专门由各种查询服务实现；所以我们的 domain 就可以非常瘦身，仅仅只需要通过聚合根来封装必要的业务规则（保证聚合内数据的强一致性）即可，然后每个聚合根做了任何的状态变更后，会产生相应的领域事件，然后事件会被持久化到 EventStore，EventStore 用来持久化所有的事件，整个 domain 的状态要恢复，只需要通过 Event Sourcing 的方式还原即可；另外，当事件持久化完成后，框架会通过事件总线将事件发布出去，然后 Process Manager 就可以响应事件，然后发送新的 command 去通知相应的聚合根去做必要的处理；

上面这个过程可以在任何一个 CQRS 的架构图（包括 enode 的架构图）中找到，我这里就不贴图了。enode 中对经典的转账场景用这种思路实现了一下，有兴趣可以去下载 enode 源代码 ，然后看一下其中的 BankTransferSample 这个例子就清楚了。另外，因为事件的响应和 Command 的发送是异步的，所以，这种架构下，聚合根的交互是异步的；

需要再次强调的一点是，聚合如果只需要关注如何实现业务规则而不需要考虑查询需求所带来的好处，那就是我们不需要在 domain 里维护各种统计信息了，而只要维护各种业务规则所潜在的必须依赖的状态信息即可；举个例子，假如一个论坛，有版块和帖子，以前，我们可能会在版块对象上有一个帖子总数的属性，当新增一个帖子时，会对这个属性加 1；而在 CQRS 架构下，domain 内的版块聚合根无需维护总帖子数这个统计信息了，总帖子数会在查询端的数据库独立维护；

从聚合和哲学的角度思考，为什么需要状态？

聚合的角度

首先，什么是状态？很简单，比如一个商品的库存信息，那么该库存信息有一个商品的数量这个属性，表示当前商品在库存中还有多少件；那么我们为什么需要记录该属性呢？也就是为什么需要记录这个状态呢？因为有业务规则的存在。以这个例子为例，因为存在“商品的库存不能为负数”这样的一个业务规则，那这个规则如果要能保证，首先必须先记录商品的库存数量；因为商品的库存数量是会随着商品的卖出而减少的，而减少就是通过：Product.Count = Product.Count - 1 这样的逻辑运算来实现；这个逻辑运算要能运行的前提就是商品要有库存信息。

从这个例子我们不难理解，一个聚合根的很多状态，不是平白无辜设计上去的，而是某些业务规则潜在的要求，必须要设计这些状态才能实现相应的业务规则；这样的例子还有很多，比如银行账号的余额不能小于 0，导致我们的银行账号必须要设计一个当前余额的属性；

另外一个原因是，看起来像是废话，呵呵。就是：因为我们关心这些信息，所以需要设计在当前聚合上；比如，以一个论坛的帖子为例，作为一个帖子，我们通常都会关心帖子的标题、描述、发帖人、发帖时间、所属版块（如果论坛有版块这个概念的话）；所以，我们就会在帖子聚合根上设计出这些属性，以表达我们所关心的这些信息的状态；

哲学的角度

下面在从偏哲学的角度表达一下对象的概念吧：

人类永远无法认识完整的事物，因为我们认识到的总是事物的某一方面。我们所说的对象实际上是客观事物在人头脑里的反应，而事物则是不因人的认识发生改变的客观存在。同样一根铁棒，在钢材生产厂家看来，它是成品；在机械加工厂家看来，它是原料；在废品站看来，他是商品。成品、原料、商品，这三者拥有不同的属性，有本质的不同。为什么同一事物在不同人的眼里就截然不同了呢？这是因为我们总是取对我们有用的方面来认识事物。当这根铁棒作为商品时，它的原料属性依然存在，只是我们不关心了。

所以，总结出来就是，因为我们关心一个对象的某些方面，所以我们才会为他设计某些状态属性；

关于聚合的设计的一些思考

上面只是简单提到，聚合的设计应该多考虑它封装了哪些业务规则这个问题。下面我想再多讲一点我的一些想法：

关于 GRASP 九大模式中的最重要模式：信息专家模式

还是以论坛的帖子为例，创建一个帖子时，有一个业务规则，那就是帖子的发帖人、标题、描述、所属板块（如果论坛有板块这个概念的话）都不能为空或无效的值，因为这些信息只要有任何一个无效，那就意味着被创建出来的帖子是无效的，那就是没有保证业务规则，也就没办法谈领域模型的数据一致性了；如果像以往的三层贫血架构，那帖子只是一个数据的载体，不包含任何业务规则，帖子会先被构造一个空的帖子对象出来，然后我们给这个空帖子对象的某些属性赋值，然后保存该帖子对象到数据库；这种设计，帖子对象只是一个数据的容器，它完全控制不了自己的状态，因为它的状态都是被别人（如 service）去修改的；这样的设计，相当于是没有把业务规则封装在业务对象内部，而是转移到了外部 service 中，虽然这样通常也没问题，事实上我们大部分人都一直在这么干，因为这样干写代码很随意，也很高效，呵呵。

GRASP 九大模式中有一个面向对象的模式叫信息专家模式，不知道大家有了解过没有，该模式的描述是：将职责分配给拥有执行该职责所需信息的对象；这个模式告诉我们，如果一个对象负责维护一些信息，那它就有职责维护好这些信息。体现到对象的属性上，那就是这个对象的属性不能被外部随便更改，对象自己的属性必须自己负责维护修改。构造函数和普通的方法都会改变对象的状态，所以，我们对构造函数和对象普通的公共方法，都要秉持这个原则；这点非常重要，否则，如果像贫血模型那样，那对象就不叫对象了，而只是一个普通的容纳数据的容器而已，和数据库里的一条记录也无本质差别了。实际上，在我看来，这也是 DDD 中的聚合区别于贫血模型中的实体的最大的地方。聚合不仅有状态，还有严格维护好自己状态的各种方法，包括构造函数在内；而贫血模型，则只有状态，没有行为；

关于 DDD 中一个领域对象是否是聚合根的考虑

这个问题，没有非常清晰的放之四海而皆准的确定方法，我的想法是：

1.  
2. 首先从我们对领域的最基本的常识方面的理解去思考，该对象是否有独立的生命周期，如果有，那基本上是聚合根了；
3. 如果领域内的一个对象，我们会在后台有一个独立的模块去管理它，那它基本上也是聚合根了；
4. 是否有独立的业务场景会去创建或修改一个对象；
5. 如果对象有全局唯一的标识，那它也是聚合根了；
6. 如果你不能确定一个对象是否是聚合根的的时候，就先放一下，就先假定它是聚合根也无妨，然后可以先分析一下你已经确定的那些聚合根应该具体聚合哪些信息；也许等你分析清楚其他的那些聚合的范围后，也推导出了你之前不确定是否是聚合根的那个对象是否应该是聚合根了呢。

关于一个聚合内应该聚合哪些信息的思考

1.  
2. 把我们所需要关心的属性设计进去；
3. 分析该聚合要封装和实现哪些业务规则，从而像上面的例子（商品库存）那样推导出需要设计哪些属性状态到该聚合内；
4. 如果我们在创建或修改一个对象时，总是会级联创建或修改一些级联信息，比如在一个任务系统，当我们创建一个任务时，可能会上传一些附件，那这些附件的描述信息（如附件 ID，附件名称，附件下载地址）就应该被聚合在任务聚合根上；
5. 聚合内只需要值对象和内部的实体即可，不需要引用其他的聚合根，引用其他的聚合根只会让当前聚合的边界模糊；

关于如何更合理的设计聚合来封装各种业务规则的思考

这一点在最上面的几个原则中，实际上已经提到过一点，那就是尽量设计小聚合，这里的出发点主要是从技术的角度去思考，为了降低对公共对象（大聚合）的并发修改，从而减小并发冲突的可能性，从而提高系统的可用性（因为系统用户不会经常因为并发冲突而导致它的操作失败）；关于这一点，我还想再举几个例子，来说明，其实要实现各种业务规则，可以有多种聚合的设计方式，大聚合只是其中一种；

比如，帖子和回复，大家都知道一个帖子有多个回复，没有帖子，回复就没有意义；所以很多人就会认为帖子应该聚合回复；但实际上不需要这样，如果你这样做了，那对于一个论坛来说，同一个帖子被多个人同时回复的可能性是非常高的，那这样的话，多个人同时回复一个帖子，就会导致多个人同时修改同一个帖子对象，那就导致大家都回复不了，因为会有并发冲突或者数据库事务的等待超时，因为大家都在修改同一个帖子聚合根；实际上如果我们从业务规则的角度去思考一下，那可以发现，其实帖子和回复之间，只有一个简单的规则，那就是回复一旦被创建，那他所对应的帖子不能被修改即可；这样的话，要实现这个规则其实很简单，把回复作为聚合根，然后把帖子传入回复聚合根的构造函数，然后回复保存帖子 ID，然后回复将帖子 ID 设置为不允许外部修改(private set;即可)，这样我们就实现了这个业务规则，同时还做到了多人同时推一个帖子回复时，不会对同一个帖子对象就并发修改，而是每个回复都是并行的往数据库插入一条回复记录即可；

所以，通过这个例子，我们发现，要实现领域模型内的各种业务规则，方法不止一种，我们除了要从业务角度考虑对象的内聚关系外，还要从技术角度考虑，但是不管从什么角度考虑，都是以实现所要求的业务规则为前提；

从这个例子，我们其实还发现了另外一件有意义的事情，那就是一个论坛中，发表帖子和发表回复是两个独立的业务场景；一个人发表了帖子，然后可能过了一段时间，另一个人对该帖子发表了回复；所以将帖子和回复都设计为独立的很容易理解；这里虽然帖子和回复是一对多，回复离开帖子确实也没意义，但是将回复设计在帖子内没任何好处，反而让系统的可用性降低；相反，像上面提到的关于创建任务时同时上传一些附件的例子，虽然一个任务也是对应多个附件信息，但是我们发现，人物的附件信息总是随着任务被创建或修改时，一起被修改的。也就是说，我们没有独立的业务场景需要独立修改任务的某个附件信息；所以，没有必要将任务的附件信息设计为独立聚合根；

ENode 框架对聚合设计和聚合之间交互的支持

enode 提供了一个基于 DDD+CQRS+Event Sourcing+In Memory+EDA 这些技术的应用开发架构；

1. enode 在框架层面就限制了一个 command 只能修改一个聚合根，这就杜绝了我们使用 Unit of Work 的模式来以事务的方式来一次性修改多个聚合根；
2. enode 提供了可靠的原子操作和并发冲突检测机制，来保证对单个聚合的操作的强一致性；
3. enode 提供了可靠的事件机制，来保证我们的 domain 中的聚合之间数据交互可以通过事件异步通信的方式来实现聚合之间的最终一致性；如果有些复杂业务场景是一个流程，那我们可以通过 Process+Process Manager 的思想来实现流程状态的跟踪和流程的流转；
4. enode 因为基于 domain event，所以，我们的聚合根不需要引用，每个聚合根只需要负责自己的状态更新，然后更新完后产生相应的 domain event 即可，这本质就是就是实现了：Don’t Ask, Tell 这个设计原则；
5. enode 提供了可靠的事件发布机制，可以确保 command side 和 query side 的数据最终一定是一致的；
6. enode 提供了 in memory 的设计，使得我们的 domain 可以非常高效的运行，持久化事件不需要事务，获取聚合根直接从 in memory 获取；
7. enode 提供了很多设计，可以让我们最大化的对不同的聚合根实例做并行操作，从而提高整个系统的吞吐量；

使用 enode，将会迫使你思考如何设计聚合，如何通过流程实现聚合之间的异步交互；迫使你思考如何定义 domain event，将领域内的状态更改显式化；迫使你将外部对领域的各种操作显式化，即定义出各种 command；迫使你将 command side 和 query side 的数据分离和架构分离，技术分离。减少的是，我们不必再设计 unit of work，不必设计 domain service，不必让聚合设计各种非第一手的冗余的统计信息；