考虑到域事件模式和这个
post,为什么人们建议每个事务模型保留一个聚合？当一个聚合可以改变另一个聚合的状态时,有很好的情况.即使删除聚合(或改变它的标识)也会导致改变引用它的其他聚合的状态.有人说每个聚合保留一个事务有助于扩展(每个服务器保留一个聚合).但这种思维方式是否打破了DDD的基本特征：技术不可知？
因此,基于上述陈述和您的经验,设计聚合,域事件导致其他聚合更改是不好的,这将导致每个事务有2个或更多聚合(例如：放置新订单时)有100个项目将客户的状态从正常更改为VIP)？
解决方法
聚合组关联业务对象,而聚合根(AR)是该聚合的“代表”. AR本身是一个模拟(更大,更复杂)域概念的实体.在DDD中,模型总是相对于上下文(有界上下文 – BC),即该模型仅在该BC中有效.
这允许您定义代表特定业务上下文的模型,并且您不需要仅在一个模型中推送所有内容.订单在一个上下文中是AR,而在另一个上下文中只是一个id.
由于AR几乎封装了所有较低概念和业务规则,因此它作为一个整体,即作为交易/工作单元.存储库始终与AR一起使用,因为1)repo始终处理业务对象,2)AR表示给定上下文的业务对象.
当您有一个涉及2个或更多AR的用例时,业务工作流和该用例的正确建模是至关重要的.在很多情况下,这些AR可以独立修改(一个不关心其他)或AR因其他AR行为而改变.
在您的示例中,它非常简单：当客户下达100个项目的订单时,会生成并发布域事件.然后你有一个处理程序,它将检查订单是否符合客户促销规则,如果是,则发出一个命令,其结果是将客户端状态更改为VIP.
域事件非常强大,允许您在最终一致的环境中实现事务.旧的db事务是一个实现细节,它通常在持久化一个AR时使用(记住AR被视为一个逻辑单元但是持久的可能涉及多个表因此db事务).
最终的一致性是域事件的“特征”,它自然适合丰富的域(实际上是现实世界).对于某些情况,您可能需要即时一致性,但这些是特定情况,它们与UI相关,而不是Domain的工作方式.当然,它确实取决于一个域到另一个域.在您的示例中,客户不会介意在下订单后2秒或2分钟成为VIP而不是相同的毫秒.
