DDD领域驱动设计实战-聚合(Aggregate)和聚合根(AggregateRoot) _aggregate

春衣少年当酒歌，起舞四顾以笑和。这篇文章主要讲述DDD领域驱动设计实战-聚合(Aggregate)和聚合根(AggregateRoot)相关的知识，希望能为你提供帮助。
实体和值对象组成聚合，再根据业务，将多个聚合划定到同一限界上下文，并在限界上下文内完成领域建模。
聚合只是单纯将一些共享父类、密切关联的对象聚集成一个对象树吗？如果是这样，对于存在于这个树中的对象，有没有一个实用的数目限制？
既然一个聚合可以引用另一个聚合，是否可以深度遍历下去，并且在此过程中修改对象？
聚合的不变条件和一致性边界是什么意思？
1 聚合

实体一般对应业务对象，具有业务属性和业务行为
值对象主要是属性集合，描述实体的状态和特征

但都只是个体化对象，其行为表现出的是个体能力。
1.1 意义
领域模型内的实体和值对象好比个体，而能让实体和值对象协同工作的组织就是聚合，用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。
聚合由业务和逻辑紧密关联的实体和值对象组合而成，是数据修改和持久化的基本单元，每个聚合对应一个仓储，实现数据的持久化。
聚合有一个聚合根和上下文边界：

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

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

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

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

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

在聚合间，它还是聚合对外的接口人，以聚合根ID关联的方式接受外部任务和请求，在上下文内实现聚合之间的业务协同。即聚合间通过聚合根ID关联引用，若需要访问其它聚合的实体，就要先访问聚合根，再导航到聚合内部实体，外部对象不能直接访问聚合内实体。
2.1 电商案例
典型的聚合根：库存、商品、订单等。
以订单为例，订单在聚合里是聚合根，与订单关联的有订单明细和收货地址：

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

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

采用事件风暴，根据业务行为，梳理出在投保过程中发生这些行为的所有的实体和值对象
从众多实体中选出适合作为对象管理者的根实体（聚合根）。判断一个实体是否是聚合根，可分析：是否有独立生命周期？是否有全局唯一ID？是否可创建或修改其它对象？是否有专门模块管这个实体
根据业务单一职责和高内聚原则，找出与聚合根关联的所有紧密依赖的实体和值对象。构建出 1 个包含聚合根（唯一）、多个实体和值对象的对象集合，这个集合就是聚合
在聚合内根据聚合根、实体和值对象的依赖关系，画出对象的引用和依赖模型。

投保人和被保人的数据，是通过关联客户ID从客户聚合中获取的，在投保聚合里它们是投保单的值对象，这些值对象的数据是客户的冗余数据，即使未来客户聚合的数据发生了变更，也不会影响投保单的值对象数据。
从图还可看出实体之间的引用关系，比如在投保聚合里投保单聚合根引用了报价单实体，报价单实体则引用了报价规则子实体。

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

4 设计原则4.1 在一致性边界内建模真正的不变条件
要从限界上下文中发现聚合，需要了解模型中真正的不变条件，才能决定什么样的对象可以放在一个聚合。不变条件表示一个业务规则，该规则应该总是保持一致。
有多种类型的一致性：

事务一致性

要求立即性和原子性

最终一致性

在讨论不变条件时，我们讨论的是事务一致性。我们可能有以下不变条件：

c = a + b

当a等于2，b等于3时，c必等于5。根据这条规则，如果c不为5，便违背系统不变条件。为保持c的一致性，应该在模型中为这些属性设计一个边界：

AggregateTypel (
int a;
int b;
int c;
operations ...

聚合边界之内的所有内容组成一套不变的业务规则，任何操作都不能违背这些规则。边界之外的任何东西与该聚合都无关。因此，聚合表达了与事务一致性边界相同的意思。该例中，AggregateTypel拥有3个int属性，任何聚合都可拥有不同类型的属性。
聚合用来封装真正的不变性，而非简单地组合对象。聚合内有一套不变的业务规则，各实体和值对象按统一业务规则运行以实现对象数据的一致性，边界之外的任何东西都与该聚合无关，所以聚合能实现高内聚！
4.2 优先小聚合
聚合设计过大，会因为包含过多实体，导致实体间管理复杂，高频操作时出现并发冲突或数据库锁，即便能保证事务成功执行，依然有可能限制系统的性能和可伸缩性。
小聚合则可降低由于业务过大导致聚合重构的可能性，让领域模型更能适应业务变化。
得多“小”呢？最极端的，一个聚合只有全局标识和单个属性，当然，这并非推荐的做法（除非正是需求所在）。推荐使用根实体（Root Entity）表示聚合，其中只包含最小数量的属性或值类型属性。
哪些属性是必需的？最简单的：必须与其他属性保持一致的。比如，一个Product拥有name、description属性，它们需要保持一致，将它们放在两个不同的聚合中根本无意义。修改name时，很可能也会同时修改description。若只修改其一，多半是在修改语法上的错误或使description能更匹配name。
在聚合中，若认为有些被包含的部分应该建模成实体，怎么办？该部分是否：

会随时间而改变
或能被全部替换

若可被全部替换，请将其建模成值对象，而非实体
很多时候，建模成实体的概念都可重构成值对象。优先选用值对象并非意味着聚合就是不变的，因为当值对象属性被替换成其他值时，根实体也就随之改变。
将聚合的内部建模成值对象有很多好处：

据所选用持久化机制，值对象可随根实体而序列化，而实体则需单独的存储区域并予以跟踪
实体还会带来一些不必要操作，如在使用Hibernate时，需对多表联合查询，而对单表读取快得多，而使用值对象也更方便安全
由于值对象不变，测试也相对简单

小聚合不仅有性能和可伸缩性上的好处，它还有助于事务成功执行，即可减少事务提交冲突。系统可用性也得到增强。
在你的领域中，迫使你设计大聚合的不变条件约束并不多。遇到这种情况，可考虑添加实体或集合，但始终都应将聚合设计得尽量小。
4.3通过唯一标识引用其它聚合
聚合之间通过关联外部聚合根ID的方式引用，而非直接对象引用。外部聚合的对象放在聚合边界内管理，容易导致聚合的边界不清晰，也会增加聚合之间的耦合度。
4.4在边界之外使用最终一致性
聚合内数据强一致性，聚合间数据最终一致性。
一次事务中，最多只能更改一个聚合的状态。若一次业务操作涉及多个聚合状态的更改，应采用领域事件异步修改相关的聚合，实现聚合间的解耦。
在不持有对象引用的情况下，不能修改其他聚合，因此可避免在同一事务中修改多个聚合。但这样限制性太强，因为在领域模型中，我们总需要对象之间的关联关系来完成任务。对此，又该怎么办呢？
4.5 通过应用层实现跨聚合的服务调用
为实现微服务内，聚合之间的解耦，还有未来以聚合为单位的微服务的组合和拆分，应避免跨聚合的领域服务调用和跨聚合的数据库表关联。
5 总结

聚合的特点

高内聚、低耦合，它是领域模型中最底层的边界，可作为拆分微服务的最小单位，但不推荐过度拆分。在对性能有极致要求的场景中，聚合可独立作为一个微服务，以满足版本的高频发布和弹性伸缩要求。
一个微服务可包含多个聚合，聚合之间的边界是微服务内天然的逻辑边界。有了该逻辑边界，在微服务架构演进时就可以聚合为单位进行拆分和组合。