因此,基于上述陈述和您的经验,设计聚合,域事件导致其他聚合更改是不好的,这将导致每个事务有2个或更多聚合(例如：放置新订单时)有100个项目将客户的状态从正常更改为VIP)？
解决方法
这允许您定义代表特定业务上下文的模型,并且您不需要仅在一个模型中推送所有内容.订单在一个上下文中是AR,而在另一个上下文中只是一个id.
由于AR几乎封装了所有较低概念和业务规则,因此它作为一个整体,即作为交易/工作单元.存储库始终与AR一起使用,因为1)repo始终处理业务对象,2)AR表示给定上下文的业务对象.
当您有一个涉及2个或更多AR的用例时,业务工作流和该用例的正确建模是至关重要的.在很多情况下,这些AR可以独立修改(一个不关心其他)或AR因其他AR行为而改变.
在您的示例中,它非常简单：当客户下达100个项目的订单时,会生成并发布域事件.然后你有一个处理程序,它将检查订单是否符合客户促销规则,如果是,则发出一个命令,其结果是将客户端状态更改为VIP.
域事件非常强大,允许您在最终一致的环境中实现事务.旧的db事务是一个实现细节,它通常在持久化一个AR时使用(记住AR被视为一个逻辑单元但是持久的可能涉及多个表因此db事务).
最终的一致性是域事件的“特征”,它自然适合丰富的域(实际上是现实世界).对于某些情况,您可能需要即时一致性,但这些是特定情况,它们与UI相关,而不是Domain的工作方式.当然,它确实取决于一个域到另一个域.在您的示例中,客户不会介意在下订单后2秒或2分钟成为VIP而不是相同的毫秒.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
