DDD - 如何在单个请求中修改多个 AR（来自不同的有界上下文）？答案

【问题标题】：DDD - How to modify several AR (from different bounded contexts) throughout single request?DDD - 如何在单个请求中修改多个 AR（来自不同的有界上下文）？
【发布时间】：2018-12-12 19:32:13
【问题描述】：

我想公开一个仍处于纸面状态的小场景，而对于 DDD 原则来说，完成起来似乎有点乏味。

假设我有一个用于托管帐户管理的应用程序。基本上，该应用程序由几个有界上下文组成，例如 Web 帐户管理、Ftp 帐户管理、邮件帐户管理......它们中的每一个都由它们自己的 AR 表示（它们可以独立存在）。

现在，假设我想提供一个带有 HTML 表单的 UI，该表单为每个有界上下文组成一个字段集，例如更新限制和/或功能。我应该如何在不破坏每个请求原则的单个事务的情况下准确地更新所有 AR？我可以创建一种“外部”AR，比如说一个 ClientHostingProperties AR，它将保存对其他 AR 的引用并使用自己的存储库将它们作为单个事务的一部分进行更新？或者我应该更好地创建一个 AR 来发出消息，让有界上下文提供的侦听器做出反应，在这种情况下，我应该考虑 ES？

谢谢。

【问题讨论】：

标签： domain-driven-design event-sourcing

【解决方案1】：

我应该如何在不破坏每个请求原则的单个事务的情况下准确地更新所有 AR？

您可能正在寻找process manager。

基本草图：保存提交表单中的详细信息本身就是一项交易（您有机会获得业务价值；第 1 步是抓住该机会）。

这为您提供了一种跟踪此任务是否“完成”的方法：您将任务中的更改与系统状态进行比较，然后触发命令（以在独立事务中运行）进行更改.

在我看来，进程最终看起来很像状态机。这些任务是命令完成了，这些命令没有完成，这些命令都失败了：现在怎么办？并最终达到不需要进行额外更改的状态，并且此流程实例已“完成”。

【讨论】：

【解决方案2】：

简短的回答：你不知道。

聚合是事务边界，这意味着如果您要在一个“操作”中更新多个聚合，则必须使用多个事务。聚合相当于一个事务的原因是这样可以保证一致性。

这意味着您有两种选择：

您可以使您的聚合更大。然后你实际上可以保证一致性，但是你处理并发请求的能力会变差。所以这通常是您要避免的。
您可以接受这是两个事务的事实，这意味着您最终是一致的。如果是这样，您通常使用诸如流程管理器或流之类的东西来处理更新多个聚合。在最简单的形式中，流只不过是一个简单的如果发生此事件，则运行该命令 规则。在更复杂的形式中，它有自己的状态。

希望对你有所帮助?

【讨论】：

我明白了，但有没有办法让一个专门的 AR 围绕其他 AR？这种方法有什么问题？
这违背了聚合的定义。根据定义，聚合是事务边界。如果您引入诸如 超级聚合 之类的东西，您实际上可以将多个聚合变成一个更大的聚合。如果这实际上是你想要做的，那么让它明确，并将聚合变成一个单一的。如果您不想这样做，请保持最终的一致性。这基本上是您拥有的两个选项。我希望这能进一步澄清一些事情。