【问题标题】:DDD: Eventual consistency and 1 to n relationshipsDDD:最终一致性和 1 对 n 关系
【发布时间】:2018-01-11 17:20:01
【问题描述】:

在我的域中,我有 Product 和 Order 聚合。订单参考产品。这是一个 1 对 n 的关系,所以一个产品有很多订单并且订单属于一个产品。当产品停产时,将发布 ProductDiscontinued 事件,并且必须取消属于该产品的所有订单。所以有一个适配器通过 RabbitMQ 接收 ProductDiscontinued 事件。然后适配器将取消订单委托给应用程序服务。如何在单笔交易中取消单笔订单?适配器是否应该迭代已停产产品的所有订单并为每个订单调用应用程序服务?我是否应该忽略我在单个事务中修改了多个聚合并仅使用所有受影响的 OrderId 列表调用应用程序服务?有没有更好的解决方案?

【问题讨论】:

  • 你使用 CQRS 吗?
  • 不,我们不使用 CQRS。
  • 据我了解,您有一个修改“n”个聚合的事件。它们应该在不同的事务(命令)中进行修改,因为它们是不同的聚合。最棘手的部分可能是管理一个失败的命令,如果你必须修改 5 个聚合并且第二个失败,你必须问自己想要发生什么?您是否需要确保所有聚合都已修改?在失败的情况下是否可以重新处理事件(聚合上的更改是否具有幂等性)?

标签: domain-driven-design


【解决方案1】:

从 DDD 的角度来看,Aggregate 是事务边界。交易不应大于聚合。存在此规则是为了强制人们正确设计聚合,而不依赖于在同一事务中修改的多个聚合。

但是,您在设计聚合时已经考虑到了这一点(据我所知)。

适配器是否应该迭代已停产产品的所有订单并为每个订单调用应用程序服务?

这是正常的做事方式。

我是否应该忽略我在单个事务中修改了多个聚合并仅使用所有受影响的 OrderId 列表调用应用程序服务?

在我之前所写的上下文中,您可以这样做,如果它以某种方式提供更好的性能(我不知道更大的事务如何能提供更好的性能,但是嘿,这取决于代码也)。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-03-05
    • 1970-01-01
    • 1970-01-01
    • 2015-06-05
    • 2020-09-07
    • 2013-02-03
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多