我想公开一个小场景，它仍然处于纸张状态，关于DDD原则，完成起来似乎有点乏味。
假设，我有一个用于托管帐户管理的应用程序。基本上，该应用程序由几个边界上下文组成，例如Web帐户管理，FTP帐户管理，邮件帐户管理...他们每个人都由自己的AR代表(他们可以独立生活(。
现在，假设我想提供一个带有 HTML 表单的 UI，该表单为每个边界上下文组成一个字段集，例如更新限制和/或功能。我应该如何准确地处理以更新所有 AR，而不会破坏每个请求的单个事务原则？我可以创建一种"外部"AR，比如说一个ClientHostingProperties AR，它将保存对其他AR的引用，并使用自己的存储库将它们作为单个事务的一部分进行更新？或者我应该更好地创建一个AR，发出消息，让边界上下文提供的听众做出反应，在这种情况下，我可能应该考虑ES？
谢谢。
简短的回答：你没有。
聚合是一个事务边界，这意味着如果要在一个"操作"中更新多个聚合，则必须使用多个事务。聚合等效于一个事务的原因是，这允许您保证一致性。
这意味着您有两种选择：
- 您可以放大聚合。然后，您实际上可以保证一致性，但处理并发请求的能力会变差。所以这通常是你想要避免的。
- 你可以接受它是两个交易的事实，这意味着你最终是一致的。如果是这样，您通常使用诸如进程管理器或流之类的东西来处理多个聚合的更新。在最简单的形式中，流只不过是一个简单的如果发生此事件，请运行该命令规则。在更复杂的形式中，它有自己的状态。
希望这有帮助 😊
我应该如何在不破坏每个请求的单个事务原则的情况下准确处理以更新所有 AR？
您可能正在寻找流程经理。
基本草图：保留提交表单中的详细信息本身就是一项交易(为您提供了获得商业价值的机会;第 1 步是抓住这个机会(。
这为您提供了一种跟踪此任务是否"完成"的方法：您将任务中的更改与系统状态进行比较，并触发命令(在隔离事务中运行(进行更改。
在我看来，进程最终看起来很像状态机。 这些任务是命令完成，这些命令没有完成，这些命令失败了：现在怎么办？ 并最终达到无需进行其他更改的状态，并且该过程的此实例已"完成"。