实体和值对象组成聚合,再根据业务,将多个聚合划定到同一限界上下文,并在限界上下文内完成领域建模。
聚合只是单纯将一些共享父类、密切关联的对象聚集成一个对象树吗?如果是这样,对于存在于这个树中的对象,有没有一个实用的数目限制? 既然一个聚合可以引用另一个聚合,是否可以深度遍历下去,并且在此过程中修改对象? 聚合的不变条件和一致性边界是什么意思?
但都只是个体化对象,其行为表现出的是个体能力。
领域模型内的实体和值对象好比个体,而能让实体和值对象协同工作的组织就是聚合,用来确保这些领域对象在实现共同的业务逻辑时,能保证数据的一致性。
聚合由业务和逻辑紧密关联的实体和值对象组合而成,是数据修改和持久化的基本单元,每个聚合对应一个仓储,实现数据的持久化。
聚合有一个聚合根和上下文边界:
按这种方式设计出来的微服务自然就是高内聚、低耦合。
聚合属于领域层,领域层包含多个聚合,共同实现核心业务逻辑。聚合内的实体以充血模型实现个体业务能力,以及业务逻辑的高内聚。
跨多个实体的业务逻辑通过领域服务来实现,跨多个聚合的业务逻辑通过应用服务来实现:
为避免由于复杂数据模型缺少统一的业务规则控制,而导致聚合、实体之间数据不一致。
传统数据模型中的每一个实体都是同级对等,若任由实体无管控地调用数据修改,可能导致实体之间数据逻辑的不一致。而若使用锁则会增加代码复杂度,降低系统性能。
若把聚合比作组织,则聚合根就是该组织负责人。聚合根也称为根实体,它不仅是实体,还是聚合的管理者。
在聚合间,它还是聚合对外的接口人,以聚合根ID关联的方式接受外部任务和请求,在上下文内实现聚合之间的业务协同。即聚合间通过聚合根ID关联引用,若需要访问其它聚合的实体,就要先访问聚合根,再导航到聚合内部实体,外部对象不能直接访问聚合内实体。
典型的聚合根:库存、商品、订单等。
以订单为例,订单在聚合里是聚合根,与订单关联的有订单明细和收货地址:
DDD领域建模通常采用事件风暴,采用用例分析、场景分析和用户旅程分析等方法,通过头脑风暴列出所有可能的业务行为和事件,然后找出产生这些行为的领域对象,并梳理领域对象之间的关系,找出聚合根,找出与聚合根业务紧密关联的实体和值对象,再将聚合根、实体和值对象组合,构建聚合。
如下为保险的投保业务场景:
投保人和被保人的数据,是通过关联客户ID从客户聚合中获取的,在投保聚合里它们是投保单的值对象,这些值对象的数据是客户的冗余数据,即使未来客户聚合的数据发生了变更,也不会影响投保单的值对象数据。 从图还可看出实体之间的引用关系,比如在投保聚合里投保单聚合根引用了报价单实体,报价单实体则引用了报价规则子实体。
要从限界上下文中发现聚合,需要了解模型中真正的不变条件,才能决定什么样的对象可以放在一个聚合。不变条件表示一个业务规则,该规则应该总是保持一致。
有多种类型的一致性:
在讨论不变条件时,我们讨论的是事务一致性。我们可能有以下不变条件:
c = a + b
当a等于2,b等于3时,c必等于5。根据这条规则,如果c不为5,便违背系统不变条件。为保持c的一致性,应该在模型中为这些属性设计一个边界:
AggregateTypel (
int a;
int b;
int c;
operations ...
聚合边界之内的所有内容组成一套不变的业务规则,任何操作都不能违背这些规则。边界之外的任何东西与该聚合都无关。因此,聚合表达了与事务一致性边界相同的意思。该例中,AggregateTypel拥有3个int属性,任何聚合都可拥有不同类型的属性。
聚合用来封装真正的不变性,而非简单地组合对象。聚合内有一套不变的业务规则,各实体和值对象按统一业务规则运行以实现对象数据的一致性,边界之外的任何东西都与该聚合无关,所以聚合能实现高内聚!
聚合设计过大,会因为包含过多实体,导致实体间管理复杂,高频操作时出现并发冲突或数据库锁,即便能保证事务成功执行,依然有可能限制系统的性能和可伸缩性。
小聚合则可降低由于业务过大导致聚合重构的可能性,让领域模型更能适应业务变化。
最极端的,一个聚合只有全局标识和单个属性,当然,这并非推荐的做法(除非正是需求所在)。推荐使用根实体(Root Entity)表示聚合,其中只包含最小数量的属性或值类型属性。
最简单的:必须与其他属性保持一致的。比如,一个Product拥有name、description属性,它们需要保持一致,将它们放在两个不同的聚合中根本无意义。修改name时,很可能也会同时修改description。若只修改其一,多半是在修改语法上的错误或使description能更匹配name。
该部分是否:
很多时候,建模成实体的概念都可重构成值对象。优先选用值对象并非意味着聚合就是不变的,因为当值对象属性被替换成其他值时,根实体也就随之改变。
将聚合的内部建模成值对象有很多好处:
小聚合不仅有性能和可伸缩性上的好处,它还有助于事务成功执行,即可减少事务提交冲突。系统可用性也得到增强。
在你的领域中,迫使你设计大聚合的不变条件约束并不多。遇到这种情况,可考虑添加实体或集合,但始终都应将聚合设计得尽量小。
聚合之间通过关联外部聚合根ID的方式引用,而非直接对象引用。外部聚合的对象放在聚合边界内管理,容易导致聚合的边界不清晰,也会增加聚合之间的耦合度。
聚合内数据强一致性,聚合间数据最终一致性。
一次事务中,最多只能更改一个聚合的状态。若一次业务操作涉及多个聚合状态的更改,应采用领域事件异步修改相关的聚合,实现聚合间的解耦。
在不持有对象引用的情况下,不能修改其他聚合,因此可避免在同一事务中修改多个聚合。但这样限制性太强,因为在领域模型中,我们总需要对象之间的关联关系来完成任务。对此,又该怎么办呢?
为实现微服务内,聚合之间的解耦,还有未来以聚合为单位的微服务的组合和拆分,应避免跨聚合的领域服务调用和跨聚合的数据库表关联。
参考