处理聚合之间一致性的最佳方法是什么？以 Vaughn Vernon 书中的示例为例，您有 BacklogItem 聚合和 SprintAggregate。当 BacklogItemEvent 引发时，事件处理程序会捕获它并尝试更新 Sprint Aggregate。如果此操作失败怎么办？如何找到处理这种情况的最佳方法？据我了解有3个选择：
1) 更新一笔事务中的所有聚合。我们失去了可扩展性，但我们获得了一致性。
2）什么也不做。只需记录错误并等待手动干预。
3）使用传奇。这使设计变得复杂，并迫使我们实现每个用例，这些用例必须在单独的对象（saga）中的聚合之间强制执行变体。如果 Sprint 更新失败，saga 将尝试取消提交 Backlog 项目（补偿）。
您会选择哪个选项？您的标准是什么？
处理聚合之间一致性的最佳方法是什么？
如果您的聚合设计正确，那么您可以随着时间的推移处理聚合之间的“一致性”（也称为：最终一致性）。
如果此操作失败怎么办？
仔细阅读竞争条件不存在 http://udidahan.com/2010/08/31/race-conditions-dont-exist/;乌迪·达汉 (Udi Dahan) 认为协作域中的操作应该not fail.
更新一笔事务中的所有聚合。
你可以这样做；但这实际上意味着这两个实体实际上是一个实体的一部分implicit总计的。换句话说，它强烈表明您没有将聚合边界放置在正确的位置。
尝试在单个事务中修改多个聚合是有效的两阶段提交，以及由此产生的所有其他复杂情况。
没做什么。只需记录错误并等待手动干预。
是的;例如，参见；格雷格·杨有什么要说的.
使用传奇。这使设计变得复杂，并迫使我们实现每个用例，这些用例必须在单独的对象（saga）中强制聚合之间的不变量。
如今，您通常会看到“流程管理器”而不是“saga”，后者具有更具体的含义。但是，是的，如果域模型需要在聚合之间进行编排，那么您将需要在某处描述编排逻辑。
您可能想回顾一下 Rinat Abdullin 的讨论不断发展的业务流程 https://abdullin.com/post/ddd-evolving-business-processes-a-la-lokad/;他提出了一个很好的论点，即自动化只是复制人类操作员会采取的行动。
您会选择哪个选项？您的标准是什么？
比起容易，我更喜欢简单。因此，我的目标是异常报告，理由是（a）无论如何，这些失败应该很少见，所以我们不想在远离幸福道路的工作中投入大量设计资本，以及（b）如果我们系统中有失败的命令，那么我们应该有一个机制来报告失败的命令anyway，所以我只是利用现有的东西。
如果我时间紧迫，如果项目还没有足够成功，需要扩展，如果我手头没有所需的报告部分，我可能更愿意将更改潜入单个事务中，然后在开发过程本身中提出异常报告，以引起人们注意以后需要做更多工作的事实。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
