再谈一下DDD中的聚合设计

news2024/12/23 16:16:19

何为聚合

在领域模型中，一些实体或者值对象具有强而有力的业务关联关系，于是这些对象就组成了一个聚合，聚合内部的业务实体之间必须保证状态一致性。从技术角度来看，聚合是数据修改与持久化的基本单元，聚合内数据修改必须由聚合根统一组织，以确保每次数据修改都按照聚合内统一的业务规则来完成

聚合为什么存在

在问题域中，不同的业务实体之间存在一些强制的业务规则。例如：订单（Order）总金额=订单行（OrderItem）明细金额之和；一个投保单必然包含投保标的......

为了保证上面的业务一致性，所以DDD中就有了聚合。聚合就是为了保证业务一致性的。

使用聚合碰到的问题：

在DDD中聚合设计的过于臃肿庞大，成为了一个对象树。“聚合根”就是最上层的对象，里面包含许多子对象的数据组或者集合。聚合保存时经常出现事务失败的情况；聚合内部子对象的修改导致整个聚合都要随之变更。

在《实现领域驱动设计》中，也举了这么一个列子：

在scrum核心领域中使用聚合。作者给出了两种聚合的表示形态

形态一：

Product被建模成一个非常大的聚合。此时Product作为一个根（root）对象而存在，它包含了所有的BacklogItem，Release和Sprint。

形态二：

将形态一中，一个大的Product聚合拆分成4个相对较小的聚合：Product、BacklogItem、Release、Sprint，它们都关联值对象ProductID。

很明显，形态二设计的更加合理。Product与BacklogItem、Release、Sprint根本不是强聚合关系。因为Product与BacklogItem、Release、Sprint不具有相同的生命周期，一个Product可以拥有多个Sprint，当Product存在时，并不是每一个Sprint都已经存在，第二个Sprint估计还不存在，反之，第二个Sprint结束了，Product很可能还没有完结。Product与BacklogItem、Release、Sprint就是松散的聚合关系，对于松散聚合关系应该设计成第二种形态。

形态三：

额外补充一下，大家都学过面相对象的分析与设计。大家会设计成形态三的样子。Product拥有自己的ID，BacklogItem、Release、Sprint则是关联一个ProductID。形态三与形态二都不承认“强聚合”关系的存在。组合与聚合都是特殊的关联关系，组合强调了整体与部分的生命周期是一致的，而聚合（弱聚合）的整体和部分之间在生命周期上没有什么必然的联系。有很多文章讲解他们区别，感兴趣的读者可以再温习一下。

如何设计聚合

原则一：强聚合设计成对象树的形态，也就是形态一；弱聚合则设计成多个聚合根引用主实体ID的形态——形态二。

学过OOA的开发应该知道“组合”与“聚合”的概念。组合就是一种强聚合，只有这种强聚合才能设计成对象树的形态（形态一），因为强聚合要保证一致性。反之，则建议拆解成多个聚合根，也就是形态二

1、如何区分“组合”与“聚合”：

组合是强聚合，内部实体具有不可违背的业务一致性关系，而且内部实体之间具有一致的生命周期。

例如在电商领域中，订单（order）与订单行(orderItem)就是强聚合，订单是聚合根，多个订单行形成子实体集合；订单（Order）总金额=订单行（orderItem）明细金额之和。但是在员工（Employee）与员工异动记录，则是弱聚合关系. 组织内部的一个员工（Employee）可以有多条“员工异动记录”，一个“员工异动记录”必然属于一个员工，但是员工异动记录与员工不具有相同的生命周期。

原则二：一个聚合内必须保证数据强一致性

这个也就是模型中真正的不变条件，是我们的业务规则的体现，我们在程序设计中会使用事务一致性来保证。思考一下，在程序设计中，是否需要“事务一致性“，如果没有，则应该怀疑这个聚合存在的合理性。

同时，在一个事务中，建议只修改一个聚合实例。

原则三：引用其他聚合的ID，而不是直接引用聚合

如何你明白形态三的设计，这一点应该很好理解。弱聚合设计成关联关系，你直接关联主实体的ID，而不是关联主实体。