在对域进行建模时,是否应该考虑"每个聚合一个事务"规则？

Question

考虑到域事件模式和这篇文章,为什么人们建议每个事务模型保留一个聚合？当一个聚合可以改变另一个聚合的状态时,有很好的情况.即使删除聚合(或改变它的标识)也会导致改变引用它的其他聚合的状态.有人说每个聚合保留一个事务有助于扩展(每个服务器保留一个聚合).但这种思维方式是否打破了DDD的基本特征:技术不可知？

因此,基于上述陈述和您的经验,设计聚合,域事件导致其他聚合更改是不好的,这将导致每个事务有2个或更多聚合(例如:放置新订单时)有100个项目将客户的状态从正常更改为VIP)？

Answer 1

这里有几件事情可以做,甚至还有更多的权衡取舍.

• 首先,你是对的,你应该首先考虑模型.毕竟,语言,模型和领域的相互作用正是我们所做的一切:提出精心设计的抽象作为问题的解决方案.
• 战术模式 - 来自DDD书 - 是达到目的的手段.在这方面,我们不应该过分强调他们,尽管他们为我们服务很好(并且给其他人带来了严重的麻烦).它们帮助我们找到模型中的"一致性单元",一起变化的事物,一个事务边界.我担心这就是问题所在.当事情发生时,当它发生的副作用应该是可见的是两件不同的事情.然而,他们往往被视为一体,从而引起这种不舒服的感觉,我们通过试图挤压边界内的所有东西来回应,而不会质疑.尽管如此,我们还是留下了那种不舒服的感觉.有很多东西在逻辑上可以被视为"整体变化",而物理上有许多小的变化.这需要技巧和经验,甚至直言不讳地知道何时是这种情况.并非所有事情都能以这种方式解决.
• 为了扩展或不扩展,这通常是个问题.如果您不需要扩展,将内容放在一个盒子上,满足于某个备份/恢复策略,您可以弯曲规则并一次性影响多个聚合.但是你必须意识到你正在这样做,而不是把它当作一个给定的,因为不可避免地会发生变化,它可能会混淆这种处理事物的特殊方式.所以,公平警告.关于为什么要一次改变多个聚合的问题,更为微妙.人们经常回答"你的聚合边界是错误的"答案.实际上,这意味着您需要进行更多的域和模型探索,以发现这些同步,多聚合更改的真正动机.通常,UI或服务是具有这种"不合理"期望的那个.但是可能还有其他原因,可能需要的是一组不同的抽象来解决同样的问题.这是DDD非常重要的一个方面.
• 您给出的示例似乎是我可以处理的两个单独的交易:订单被放置,并作为对此的反应,因为订单放置了100个项目,客户成为VIP.正如MikeSW在他的回答中暗示的那样(我在发布他之后开始写我的),问题是何时,是谁,如何以及为什么要观察这种客户状态.基本上,它是"下一步"行为,它决定了先前行为的一致性要求.