实体（Entity）和值对象（ValueObject）组成聚合(Aggregate)，再根据业务将多个聚合划定到同一限界上下文（Bounded Context），并在限界上下文内完成领域建模。
聚合只是单纯将一些共享父类、密切关联的对象聚集成一个对象树吗？
如果是这样，对于存在于这个树中的对象有没有一个实用的数目限制？
既然一个聚合可以引用另一个聚合，是否可以深度遍历下去，并且在此过程中修改对象？
聚合的不变条件和一致性边界究竟什么意思？
1 聚合
- 实体一般对应业务对象，具有业务属性和业务行为
- 值对象主要是属性集合，描述实体的状态和特征
但都只是个体化对象，其行为表现出的是个体能力。
1.1 意义
领域模型内的实体和值对象好比个体，而能让实体和值对象协同工作的组织就是聚合，用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。
聚合就是由业务和逻辑紧密关联的实体和值对象组合而成，聚合是数据修改和持久化的基本单元，每个聚合对应一个仓储，实现数据的持久化。
聚合有一个聚合根和上下文边界：
- 该边界根据业务单一职责和高内聚原则，定义了聚合内部应该包含哪些实体和值对象
- 聚合之间的边界是松耦合的
按这种方式设计出来的微服务自然就是高内聚、低耦合。
聚合属领域层，领域层包含多个聚合，共同实现核心业务逻辑。
聚合内实体以充血模型实现个体业务能力，以及业务逻辑的高内聚。跨多个实体的业务逻辑通过领域服务来实现，跨多个聚合的业务逻辑通过应用服务来实现。比如
- 有的业务需同一聚合的A和B两个实体共同完成，就可将这段业务逻辑用领域服务实现
- 有的业务需聚合C和聚合D中的两个服务共同完成，使用应用服务来组合这俩服务
2 聚合根
为避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致。
传统数据模型中的每一个实体都是同级对等，若任由实体无管控地调用数据修改，可能导致实体之间数据逻辑的不一致。而若使用锁则会增加代码复杂度，降低系统性能。
若把聚合比作组织，则聚合根就是该组织负责人。
聚合根也称为根实体，它不仅是实体，还是聚合的管理者。
- 作为实体，拥有实体的属性和业务行为，实现自身的业务逻辑
- 作为聚合的管理者，在聚合内部负责协调实体和值对象按照固定业务规则协同完成共同的业务逻辑
在聚合间，它还是聚合对外的接口人，以聚合根ID关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同。即聚合间通过聚合根ID关联引用，若需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。
2.1 电商案例
电商里面比较典型的几个聚合根，比如：库存、商品、订单等。
以订单为例，订单在聚合里是聚合根，与订单关联的有订单明细和收货地址：
- 订单明细包括商品ID、商品名称、价格及数量等信息。由于订单明细是多个，它是一个集合，它被设计为实体，被订单引用
- 订单只有一个收货地址，收货地址的值源于你的个人中心维护的收货地址，收货地址只能被整体替换，所以设计为值对象
设计聚合
DDD领域建模通常采用事件风暴，采用用例分析、场景分析和用户旅程分析等方法，通过头脑风暴列出所有可能的业务行为和事件，然后找出产生这些行为的领域对象，并梳理领域对象之间的关系，找出聚合根，找出与聚合根业务紧密关联的实体和值对象，再将聚合根、实体和值对象组合，构建聚合。
聚合诞生的完整过程案例
保险的投保业务场景
采用事件风暴，根据业务行为，梳理出在投保过程中发生这些行为的所有的实体和值对象，如投保单、标的、客户、被保人
从众多实体中选出适合作为对象管理者的根实体（聚合根）。判断一个实体是否是聚合根，可分析：是否有独立生命周期？是否有全局唯一ID？是否可创建或修改其它对象？是否有专门模块管这个实体。即投保单和客户聚合根
根据业务单一职责和高内聚原则，找出与聚合根关联的所有紧密依赖的实体和值对象。构建出 1 个包含聚合根（唯一）、多个实体和值对象的对象集合，这个集合就是聚合。即客户、投保聚合
在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。
投保人和被保人的数据，是通过关联客户ID从客户聚合中获取的，在投保聚合里它们是投保单的值对象，这些值对象的数据是客户的冗余数据，即使未来客户聚合的数据发生了变更，也不会影响投保单的值对象数据。
从图还可看出实体之间的引用关系，比如在投保聚合里投保单聚合根引用了报价单实体，报价单实体则引用了报价规则子实体。
多个聚合根据业务语义和上下文一起划分到同一个限界上下文内。
