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

我想公开一个仍处于纸面状态的小场景，关于DDD原理，它看起来有点乏味

比如说，我有一个托管帐户管理的应用程序。基本上，该应用程序由几个有限的上下文组成，如Web帐户管理、Ftp帐户管理、邮件帐户管理。。。他们每个人都有自己的AR（他们可以独立生活）

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

谢谢

我应该如何准确地处理以更新所有AR，而不破坏每个请求的单个事务原则

你可能正在找一个新的工作

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

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

---

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

简短回答：您没有

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

这意味着您有两个选择：

您可以使聚合更大。然后，您实际上可以保证一致性，但您处理并发请求的能力会变得更差。所以这通常是你想要避免的

你可以接受这样一个事实：它是两个事务，这意味着你最终是一致的。如果是这样，您通常使用诸如流程管理器或流之类的工具来处理多个聚合的更新。在其最简单的形式中，流只不过是一个简单的事件。如果发生此事件，请运行该命令规则。在更复杂的形式中，它有自己的状态

---

希望这有助于我理解这一点，但是没有办法让一个特定的AR围绕另一个AR吗？这种方法有什么错？它违背了聚合的定义。根据定义，聚合是事务边界。如果您引入了超级聚合之类的东西，则可以有效地将多个聚合转化为单个更大的聚合。如果这确实是您想要做的，那么将其显式化，并将聚合转化为单个聚合。如果你不想这样做，那就要保持最终的一致性。这基本上是你的两个选择。我希望这能让事情澄清一点。