从战术设计上,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、聚合就是构建一棵聚合树