每笔交易有多个汇总根实例 [英] Multiple Aggregates Root INSTANCES per transaction

问题描述

在DDD中，聚合应该代表事务边界。一项交易需要涉及多个汇总，这通常表明该模型应该完善，或者交易需求应进行审查，或者两者都需要。

In DDD the Aggregate should represent the transactional boundary. A transaction that requires the involvement of more than one aggregate is often a sign that either the model should be refined, or the transactional requirements should be reviewed, or both.

说我有一个聚合根，称为节点，在每个节点中都有一个集合字段（值对象）。每个字段都是类型，并且可以是节点类型。就我而言，如果它是节点类型，则将ID存储到节点聚合根。

Say I have an aggregate root called "Node", within each "Node" I have a collection of "Fields (Value objects)". Each "Field" is of a Type, and can be of Type "Node". In my case, if it is of Type "Node", I will store the Id to the "Node" aggregate Root.

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

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

如果我有一个更新两个AggregateRoots实例的事务，那是否有效？

If I have a transaction that updates both AggregateRoots Instances, is that valid?

或者这是否意味着如果我具有节点聚合和元素聚合，而我无法在一次交易中更新它们两者？

Or does it mean if I have "Node" aggregate and "Element" aggregate that I cannot update both of them in one transaction?

推荐答案

我认为AR可能更多地是关于一致性边界而不是交易边界。

I think an AR may be more about the consistency boundary than the transaction boundary.

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

The fact that a transaction happens to fit nicely around an AR boundary is just coincidence.

由于事务是更多地涉及应用层，如果您在一个事务中最终获得了多个AR，那么它并不一定表示设计问题。

Since transactions are more of an application layer concern, if you end up with more than one AR in a transaction then it does not necessarily indicate a design issue.

实际上，我会甚至可以说，在100％一致性要求的情况下，您甚至可能没有选择，而是将所有更改都包含在一笔交易中。

In fact, I would go so far as to say that in some 100% consistency requirement scenarios you may not even have a choice but to include all changes in one transaction.

这篇关于每笔交易有多个汇总根实例的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！