Multiple Aggregates Root INSTANCES per transaction

Question

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.

Does it mean the transaction boundary is per aggregate root INSTANCE or per aggregate?

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)

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?

Bare

Answer 1

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

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

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.

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.

Prosy

That's partially wrong, AR are consistency boundaries, but also AR are transactionnal boundaries. By allowing more than one aggregate to be modified per transaction you will be increasing the risk of false concurrency exceptions up to the point where the system could become unusable. Multiple AR can be created per transaction however. – Tetradymite

So are you saying that it is also partially correct? :) One shouldn't run into the scenario too often and it may very well indicate a design issue and there may be different ways around it. Take transferring money between two accounts. If an account is an AR then you probably want both 100% consistent. However, in the real world there is seldom control over both accounts so eventual consistency will have to suffice. Anyway, I do agree that one should try to avoid these scenarios if at all possible. – Prosy

Answer 2

Say you happen to be working with CQRS in an Async model then most likely your aggregate boundaries will become the only aggregate changed within that transaction. Now that is completely the opposite if you are using CQRS in a sync model or even if you are doing RPC N-Tier development style, where in a client call a good few changes are performed against you data model. In this last case scenario, you will definitely have multiple instances of aggregates within the same transaction (i.e.: unit of work with transaction scope).

I don´t think there is a right or wrong answer to your question without knowing more about the architecture of your system. DDD on its own cannot set the rules for your system wide transactions. What I can say for sure, is, if you happen to be using an async, event based system with cqrs and happen to be changing more than one aggregate per transaction, then, and this is just my opinion, something does not seem to be right.

Bernadette