Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Multiple Aggregates Root INSTANCES per transaction

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?

like image 763
Joshscorp Avatar asked May 05 '14 01:05

Joshscorp


People also ask

Can a bounded context have multiple aggregate roots?

Each Microservice uses its own database to persist data of domain model of a Bounded Context. A single Bounded Context can include many aggregate roots, or we can organise a single aggregate root into a single Bounded Context.

Can an aggregate root reference another aggregate root?

What you cannot do is reference anything inside the other aggregate root.

How many aggregates are in a bounded context?

I suppose, that it's fine to have maximum 3-4 aggregates per single bounded context. If there are more aggregates in single bounded context, then there are probably some issues with the software design.

What is aggregate and aggregate root in DDD?

An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each AGGREGATE has a root and a boundary. The boundary defines what is inside the AGGREGATE. The root is a single, specific ENTITY contained in the AGGREGATE.


1 Answers

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.

like image 121
Eben Roux Avatar answered Sep 23 '22 09:09

Eben Roux