如何处理 DDD 中聚合之间的最终一致性失败？答案

【问题标题】：How to handle failures in eventual consistency between aggregates in DDD?如何处理 DDD 中聚合之间的最终一致性失败？
【发布时间】：2016-03-19 14:04:16
【问题描述】：

假设我正在使用 C# 和实体框架实现领域驱动设计。

我的代码结构使得每个聚合在 EF 中都有自己的 dbcontext，以尊重聚合周围的事务边界原则。

Aggregate 1，InventoryAggregate 和 Aggregate 2，OrderAggregate，正在被某个业务流程 AddItemToOrder 更新。

在 OrderAggregate 添加项目后，它会触发一个域事件 ItemAddedToOrder，该事件由 InventoryAggregate 侦听，然后执行一些业务流程 SubtractQuantityFromInventory。

InventoryAggregate 未能减去库存，它触发了一个域事件 NotEnoughInventory，OrderAggregate 监听了该事件。

OrderAggregate 然后尝试从订单中删除该项目但失败。

现在订单中有一件不应该的商品，因为我们实际上没有足够的库存来出售该商品。

应该如何处理？

【问题讨论】：

标签： c# entity-framework domain-driven-design eventual-consistency

【解决方案1】：

您所描述的是一个流程管理器。您可能需要某种OrderProcess 或QuoteProcess AR 来处理您处理的状态。如果您需要执行一些业务验证，例如首先检查库存，那么您需要有一个流程管理器，以便您只有在确定确实可以提交后才创建实际的 Order。

关于如何处理某些项目的规则可能不像删除项目那么简单，即使在您的情况下，这可能是您需要做的。您可能需要通过一个或多个选项向用户呈现数据。一种可能是在提交订单之前将商品从其中移除，另一种可能是将其置于延期交货的订单中。

【讨论】：

可能是我正在尝试解决一个不切实际的问题，但我认为这种交换是在验证通过后发生的。 OrderAggregate 可能由于网络故障或磁盘写入问题而失败。在事务一致性下，整个事务会回滚，但在聚合之间的最终一致性下，我们必须假设下一个聚合将变得一致。
您的问题可能并不是那么不切实际。不过，人们可以用不同的方式来处理它。例如，如果您确定从一个 AR“发送”到另一个 AR 的特定消息是 100% 正确的，并且它可能失败的唯一原因是技术并且您有保证的消息传递机制，那么您可以安全地假设您的其他聚合最终将变得一致。但是，由于业务状况，消息处理可能会失败，您需要以某种方式进行补偿，然后您将需要一个流程或用流程语义污染您的其他 AR。