从战术设计上，DDD 最值得借鉴的就是聚合根

什么是聚合

将实体和值对象在一致性边界之内组合聚合

这里的一致性包括
1、业务概念的完整性
2、业务规则的一致性：多个实体需要在一次操作中保持某种一致性（修改 A，同步必须修改 B）。
3、事务一致性：即时性和原子性。一个聚合操作对应一个事务，同一事务中要避免修改多个聚合。如果非要这么做，通过最终一致性来实现。
4、最终一致性

要点

1、要求充血模型。
2、客户端只能通过聚合修改聚合内的实体对象。但是可以访问聚合内的对象
3、尽量将聚合中的实体实现为值对象
4、通常情况下，聚合中不应该依赖资源库和领域服务
5、事务一致性的边界是聚合
6、业务规则是事务的驱动力，也是聚合的驱动力

聚合根四原则

1、在一致性边界之内建模真正的不变条件（在聚合边界内保护业务规则不变性）
2、设计小聚合（聚合要设计得小巧）
3、通过唯一标识引用其他聚合根（只能通过标识符引用其他聚合）
4、在边界之外使用最终一致性（使用最终一致性更新其他聚合）

注：括号内为领域驱动精萃对四条原则的刷新

聚合四原则之间的关系

聚合理解的关键在于什么是一致性边界。一致性边界就如单一原则一样，case by case。但有几个因素会影响聚合的划分。

聚合的一致性 -> 业务的一致性 -> 事务的一致性

事务一致性的问题：事务太大，导致性能和伸缩性问题
解决思路：
1、聚合应该尽量小（更容易测试、单一职责）

小聚合的问题：小聚合导致一个业务操作包含多个聚合
解决思路
1、多个聚合之间通过唯一标识相互引用
2、多个聚合的一致性通过最终一致性来实现
3、多个聚合导致的查询性能问题可以通过 theta 联合查询和 CQRS 来解决

最终一致性的问题：影响用户体验
解决思路
1、重新设计业务规则
2、考虑增加聚合的可行性

聚合根的实现受非功能需求的影响
1、大的聚合根需要更多的内存
2、大的聚合根会带来大事务
3、太小的聚合根会导致多次事务操作，影响用户体验
4、从即时性和可容忍的延迟会影响聚合根的范围

聚合四原则的例外

1、方便用户界面：比如一次给多个聚合定义共有属性，然后进行批量处理。
2、缺乏技术支持：一个事务对应一个聚合背后是性能和伸缩性，如果评估之后不存在性能和伸缩性，可以在一个事务中修改多个实例。
3、全局事务：性能和伸缩性可以满足
4、查询性能

事实上，如果你的系统不是大规模分布式系统，也许采用 DDD 就是错误的。

聚合设计步骤

1、将所有的实体认为是聚合
2、根据业务规则将有一致性，决定是否需要将两个聚合合并
3、对于需要合并的聚合，通过一致性更新的时间时长分为：1）即时；2）在 n 秒后。如果为1）就表示要合并。如果为 2），则表示不需要合并，通过最终一致性。

误区

1、聚合就是构建一棵聚合树