什么是聚合根

聚合

将实体（Entity）和值对象（ValueObject）组成聚合(Aggregate)，再根据业务语义将多个聚合划定到同一个限界上下文（Bounded Context）中，并在限界上下文内完成领域建模。实体一般对应业务对象，具有业务属性和业务行为，值对象主要是属性集合，描述实体的状态和特征，但都只是个体化对象，其行为表现出的是个体能力。
领域模型内的实体和值对象好比个体，而能让实体和值对象协同工作的组织就是聚合，用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。
聚合就是由业务和逻辑紧密关联的实体和值对象组合而成，聚合是数据修改和持久化的基本单元，每个聚合对应一个仓储，实现数据的持久化。
聚合有一个聚合根和上下文边界：

  • 该边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象
  • 聚合之间的边界是松耦合的

按这种方式设计出来的微服务自然就是高内聚、低耦合。
聚合在DDD分层架构属领域层，领域层包含多个聚合，共同实现核心业务逻辑。聚合内实体以充血模型实现个体业务能力，以及业务逻辑的高内聚。跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现。比如

  • 有的业务需同一聚合的A和B两个实体共同完成，就可将这段业务逻辑用领域服务实现
  • 有的业务需聚合C和聚合D中的两个服务共同完成，使用应用服务来组合这俩服务。

聚合根

主要为避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性问题。
传统数据模型中的每一个实体都是对等的，如果任由实体进行无控制地调用和数据修改，很可能会导致实体之间数据逻辑的不一致。而若使用锁则会增加代码复杂度，降低系统性能。
若把聚合比作组织，那聚合根就是该组织负责人。 聚合根也称为根实体，它不仅是实体，还是聚合的管理者。

  • 作为实体，拥有实体的属性和业务行为，实现自身的业务逻辑
  • 作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定业务规则协同完成共同的业务逻辑

在聚合间，它还是聚合对外的接口人，以聚合根ID关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同。即聚合间通过聚合根ID关联引用，若需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。

电商案例

电商里面比较典型的几个聚合根，比如：库存、商品、订单等。 以订单为例，订单在聚合里是聚合根，与订单关联的有订单明细和收货地址：

  • 订单明细包括商品ID,商品名称，价格以及数量等信息，由于订单明细是多个，它是一个集合，它被设计为实体，被订单引用
  • 而订单只有一个收货地址，这个收货地址的值来源于你个人中心维护的收货地址，收货地址只能被整体替换，所以它被设计为值对象

电商场景的聚合根设计案例（红色代表聚合根，蓝色代表聚合内的实体，灰色代表值对象）
image.png
划分与确定理由
1）订单、客户与产品都可以在不同的领域被独立访问到，所以应该是属于不同聚合的聚合根。
2）订单初看好像要依赖于客户才能存在，其实不然，一是订单的生命周期与客户的生命周期不是一致的，二是订单与客户之间也没有不变的一致性规则。
3）订单只需要下订单那个时刻客户的姓名、电话与地址等相关信息，所以作了一个值对象保存那个时刻的客户相关信息，因可能业务上需要通过订单查询客户当前的信息，所以做了一个客户ID关联到客户对象。
4）订单项也只需要那个时刻的产品的名称、单价等信息，所以作了一个值对象保存那个时刻的产品相关信息，因可能业务上需要通过订单项查询产品当前的信息，所以作了一个产品ID关联到产品对象。
5）产品初看好像要依赖于产品类别，实际上产品类别只是对产品的一种划分，所以产品类别做成值对象，如果业务上要对某个产品类别进行促销等业务逻辑，则产品类别应该划为一个单独聚合的聚合根。

设计聚合

DDD领域建模通常采用事件风暴，采用用例分析、场景分析和用户旅程分析等方法，通过头脑风暴列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象，并梳理领域对象之间的关系，找出聚合根，找出与聚合根业务紧密关联的实体和值对象，再将聚合根、实体和值对象组合，构建聚合。

聚合诞生的完整过程案例

保险的投保业务场景
image.png

  1. 采用事件风暴，根据业务行为，梳理出在投保过程中发生这些行为的所有的实体和值对象，比如投保单、标的、客户、被保人等
  2. 从众多实体中选出适合作为对象管理者的根实体（聚合根）。判断一个实体是否是聚合根，可分析：是否有独立生命周期？是否有全局唯一ID？是否可创建或修改其它对象？是否有专门模块管这个实体。图中的聚合根分别是投保单和客户实体
  3. 根据业务单一职责和高内聚原则，找出与聚合根关联的所有紧密依赖的实体和值对象。构建出 1 个包含聚合根（唯一）、多个实体和值对象的对象集合，这个集合就是聚合。图中的客户和投保这两个聚合
  4. 在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。
  5. 投保人和被保人的数据，是通过关联客户ID从客户聚合中获取的，在投保聚合里它们是投保单的值对象，这些值对象的数据是客户的冗余数据，即使未来客户聚合的数据发生了变更，也不会影响投保单的值对象数据。 从图还可看出实体之间的引用关系，比如在投保聚合里投保单聚合根引用了报价单实体，报价单实体则引用了报价规则子实体。

  6. 将多个聚合根据业务语义和上下文一起划分到同一个限界上下文内

    聚合跟的一些设计原则

    1. 在一致性边界内建模真正的不变条件。聚合用来封装真正的不变性，而不是简单地将对象组合在一起。聚合内有一套不变的业务规则，各实体和值对象按照统一的业务规则运行，实现对象数据的一致性，边界之外的任何东西都与该聚合无关，这就是聚合能实现业务高内聚的原因。
    2. 设计小聚合。如果聚合设计得过大，聚合会因为包含过多的实体，导致实体之间的管理过于复杂，高频操作时会出现并发冲突或者数据库锁，最终导致系统可用性变差。而小聚合设计则可以降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务的变化。
    3. 通过唯一标识引用其它聚合。聚合之间是通过关联外部聚合根ID的方式引用，而不是直接对象引用的方式。外部聚合的对象放在聚合边界内管理，容易导致聚合的边界不清晰，也会增加聚合之间的耦合度。
    4. 在边界之外使用最终一致性。聚合内数据强一致性，而聚合之间数据最终一致性。在一次事务中，最多只能更改一个聚合的状态。如果一次业务操作涉及多个聚合状态的更改，应采用领域事件的方式异步修改相关的聚合，实现聚合之间的解耦（相关内容我会在领域事件部分详解）。
    5. 通过应用层实现跨聚合的服务调用。为实现微服务内聚合之间的解耦，以及未来以聚合为单位的微服务组合和拆分，应避免跨聚合的领域服务调用和跨聚合的数据库表关联。

    参考资料

    理解聚合(Aggregate)和聚合根(AggregateRoot)

    https://cloud.tencent.com/developer/article/1791310

    附录

    原文地址：
    https://blog.didispace.com/txh-ddd-juhesheji/
    https://www.cnblogs.com/netfocus/p/3307971.html

    DDD社区官网上一篇关于聚合设计的几个原则的简单讨论

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

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

  8. 聚合应尽量设计的小；
  9. 聚合之间的关联通过ID，而不是对象引用；
  10. 聚合内强一致性，聚合之间最终一致性；

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

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

这个原则，就是强调聚合的真正用途除了封装我们本身所关心的信息外，最主要的目的是为了封装业务规则，保证数据的一致性。在我看来，这一点是设计聚合时最重要和最需要考虑的点；当我们在设计聚合时，要多想想当前聚合封装了哪些业务规则，实现了哪些数据一致性。所谓的业务规则是指，比如一个银行账号的余额不能小于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中一个领域对象是否是聚合根的考虑

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

  6. 首先从我们对领域的最基本的常识方面的理解去思考，该对象是否有独立的生命周期，如果有，那基本上是聚合根了；

  7. 如果领域内的一个对象，我们会在后台有一个独立的模块去管理它，那它基本上也是聚合根了；
  8. 是否有独立的业务场景会去创建或修改一个对象；
  9. 如果对象有全局唯一的标识，那它也是聚合根了；

  10. 如果你不能确定一个对象是否是聚合根的的时候，就先放一下，就先假定它是聚合根也无妨，然后可以先分析一下你已经确定的那些聚合根应该具体聚合哪些信息；也许等你分析清楚其他的那些聚合的范围后，也推导出了你之前不确定是否是聚合根的那个对象是否应该是聚合根了呢。

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

  11. 把我们所需要关心的属性设计进去；

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

  15. 聚合内的实体和值对象应该具有相同的生命周期，整个聚合是一个整体，从外部看就像是一个对象一样，聚合应该遵循同生共死的原则；

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

    这一点在最上面的几个原则中，实际上已经提到过一点，那就是尽量设计小聚合，这里的出发点主要是从技术的角度去思考，为了降低对公共对象（大聚合）的并发修改，从而减小并发冲突的可能性，从而提高系统的可用性（因为系统用户不会经常因为并发冲突而导致它的操作失败）；关于这一点，我还想再举几个例子，来说明，其实要实现各种业务规则，可以有多种聚合的设计方式，大聚合只是其中一种；
    比如，帖子和回复，大家都知道一个帖子有多个回复，没有帖子，回复就没有意义；所以很多人就会认为帖子应该聚合回复；但实际上不需要这样，如果你这样做了，那对于一个论坛来说，同一个帖子被多个人同时回复的可能性是非常高的，那这样的话，多个人同时回复一个帖子，就会导致多个人同时修改同一个帖子对象，那就导致大家都回复不了，因为会有并发冲突或者数据库事务的等待超时，因为大家都在修改同一个帖子聚合根；实际上如果我们从业务规则的角度去思考一下，那可以发现，其实帖子和回复之间，只有一个简单的规则，那就是回复一旦被创建，那他所对应的帖子不能被修改即可；这样的话，要实现这个规则其实很简单，把回复作为聚合根，然后把帖子传入回复聚合根的构造函数，然后回复保存帖子ID，然后回复将帖子ID设置为不允许外部修改(private set;即可)，这样我们就实现了这个业务规则，同时还做到了多人同时推一个帖子回复时，不会对同一个帖子对象就并发修改，而是每个回复都是并行的往数据库插入一条回复记录即可；
    所以，通过这个例子，我们发现，要实现领域模型内的各种业务规则，方法不止一种，我们除了要从业务角度考虑对象的内聚关系外，还要从技术角度考虑，但是不管从什么角度考虑，都是以实现所要求的业务规则为前提；
    从这个例子，我们其实还发现了另外一件有意义的事情，那就是一个论坛中，发表帖子和发表回复是两个独立的业务场景；一个人发表了帖子，然后可能过了一段时间，另一个人对该帖子发表了回复；所以将帖子和回复都设计为独立的很容易理解；这里虽然帖子和回复是一对多，回复离开帖子确实也没意义，但是将回复设计在帖子内没任何好处，反而让系统的可用性降低；相反，像上面提到的关于创建任务时同时上传一些附件的例子，虽然一个任务也是对应多个附件信息，但是我们发现，人物的附件信息总是随着任务被创建或修改时，一起被修改的。也就是说，我们没有独立的业务场景需要独立修改任务的某个附件信息；所以，没有必要将任务的附件信息设计为独立聚合根；

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

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

  16. enode在框架层面就限制了一个command只能修改一个聚合根，这就杜绝了我们使用Unit of Work的模式来以事务的方式来一次性修改多个聚合根；

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

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