Transactions 每个事务聚合多个根实例

在DDD中，聚合应表示事务边界。一个需要多个聚合参与的事务通常是一个迹象，表明要么应该细化模型，要么应该审查事务需求，要么两者兼而有之

这意味着事务边界是每个聚合根实例还是每个聚合

假设我有一个称为“节点”的聚合根，在每个“节点”中我有一个“字段（值对象）”的集合。每个“字段”都是一种类型，可以是“节点”类型。在我的例子中，如果它是“Node”类型，我将把Id存储到“Node”聚合根中

Node (AggregateRootID 1)
---> Field1 : String (John)
---> Field2 : String (Doe)
---> Field3 : Node (AggregateRootID 2)

Node (AggregateRootID 2)
--> Field1 : String (Jane)
--> Field2 : String (Doe)

如果我有一个更新两个AggregateRoots实例的事务，该事务有效吗

---

或者这是否意味着如果我有“节点”聚合和“元素”聚合，我就不能在一个事务中同时更新它们？

我认为AR可能更多地是关于一致性边界，而不是事务边界

一个事务恰好适合AR边界这一事实只是巧合

因为事务更多的是应用层的问题，如果事务中有多个AR，那么它不一定表示设计问题

---

事实上，我甚至可以说，在某些100%一致性需求场景中，您甚至可能没有选择，只能在一个事务中包含所有更改。

如果您碰巧在异步模型中使用CQR，那么您的聚合边界很可能会成为该事务中唯一更改的聚合。现在，如果您在同步模型中使用CQR，或者即使您使用的是RPC N层开发风格，在客户端调用中，对您的数据模型执行一些更改，那么情况就完全相反了。在最后一种情况下，您肯定会在同一事务中有多个聚合实例（即：具有事务范围的工作单元）

---

我不认为在不了解系统架构的情况下，对您的问题有正确或错误的答案。DDD本身无法为系统范围的事务设置规则。我可以肯定的是，如果您碰巧使用了一个异步的、基于事件的系统和CQR，并且碰巧每个事务更改了多个聚合，那么，这只是我的观点，有些事情似乎不正确。

部分错误，AR是一致性边界，但AR也是事务性边界。通过允许每个事务修改多个聚合，您将增加错误并发异常的风险，直到系统无法使用为止。但是，每个事务可以创建多个AR。那么，您是说它也是部分正确的吗？：）人们不应该经常遇到这种情况，这很可能表明存在设计问题，可能有不同的解决方法。在两个账户之间转账。如果一个帐户是AR，那么您可能希望两者100%一致。然而，在现实世界中，对这两个账户几乎没有控制权，因此最终的一致性就足够了。无论如何，我同意，如果可能的话，应该尽量避免这些情况。