Domain driven design 使用流程管理器（又称saga）在同一有界上下文中跨聚合根的最终一致性

假设在有界上下文中有两个聚合，它们之间有一些约束。使用DDD时，不能在同一事务中强制执行这些聚合间约束，即聚合边界是事务边界

---

<>你会考虑在微软CQRS旅程中使用什么叫做“过程管理器”来协调同一个有界上下文中的两个聚合，或者是一个进程管理器只用于在两个有界上下文之间进行协调？在同一个有界上下文中协调两个或多个聚合根的流程管理器的等价物是什么？

默认情况下，聚合根定义有界上下文，尽管是较低级别的上下文（顺便说一句，您可以找到的最低级别有界上下文是一个对象，任何对象）。流程管理器是他们使用的名称，而不是传奇故事，可以肯定的是，你也可以想出其他名称，没关系，它们都有相同的目的

是的，我会考虑使用传奇来达到最终的一致性。事实上，我认为这是最好的方法，这正是我在自己的应用程序中所做的。无论如何，我使用的是消息驱动的体系结构（是的，在本地非分布式应用程序中），我通过服务总线（我自己的，尚未发布）自动获得了saga支持

---

在处理最终一致性时，重要的是确保处处幂等。也就是说，聚合根应该拒绝重复操作，当然，事件处理程序应该能够处理同一事件可以多次发布的事实。但是，请注意，不能保证100%幂等性，但可以非常接近。

+1。回答得很好。我甚至不会说AR本身就定义了BC，但完全同意其他一切。这是一个很好的答案，但夸大了一点。只是澄清一下：有界上下文是一个模型边界，而不是聚合或对象边界（c.f.第8页）。将聚合和对象与有界上下文混为一谈太简化了。有界上下文中的模型通常由多个聚合组成。对象和聚合根（作为聚合的外观）都是如此为一些模型定义明确的边界。每个BC只是一组较小的BC。我知道当说BC时，它是关于一个较高级别的BC，但即使是较低级别的对象也与有界上下文定义相匹配。这只是证明了DDD的概念即使在对象级别也是合理的。也许这就是为什么有些人说DDD只是OOP完成得很好t、 Saga是一个协调器，如果你将你的聚合视为有界上下文，那么你将有订单、发货、付款。然后你将创建一个Saga，协调电子商务网站上的商品销售流程。想象你的流程是下单、付款、发货。现在，当你可以无需付款就发货给VIP客户并让他们付款时会发生什么60天后付款？如果VIP拥有超过10个订单，明天VIP是Visa金卡持有人，之后VIP客户的发货地址在VIP国家列表中，那该怎么办？你能将3个有界上下文中的所有数据收集到saga中吗？我不建议使用saga来实现聚合一致性，编排优先于编排。如果第二个聚合未能处理请求，请让我将系统置于一致状态