CODEWITHSUNDEEP
domain-driven-designaggregate
Normand Bedard
Normand Bedard

Reputation: 2685

DDD - Two aggregate roots sharing same database table in a single bounded context

I have a first aggregate root having a natural Id encapsulating invariants related to a same topic.

Suddently, a new business requirement arises with a new set of invariants on a completely different topic than the first aggregate. It is a great occasion to create a new aggregate root in same bounded context.

However, both aggregate roots have the same natural Id. And both aggregate roots have some identical properties (but not all). Those identical properties can be modified, but I don't want to kick-in a flow of domain events to propagate data changes in those two aggregates (because we cannot modify two aggregates in the same transaction).

An option would be to regroup those aggregate roots. They are in the same bounded context and they have the same natural Id (they "represent" the same thing) so it feels natural. But with that option, the aggregate would become HUGE. Size is not a real problem, but merging really different kinds of invariants bother me.

What about keeping those aggregates separated in the domain, but rely on the same database table to share the data?

Any opinion on that? On another alternative?

Upvotes: 3

Views: 2167

Answers (1)

Mohamed Bouallegue
Mohamed Bouallegue

Reputation: 1362

One of the biggest advantage of using aggregates is to enforce invariants and make sure that the aggregate is always in a valid state. This can be guaranteed because the aggregate root ensure the integrity of the aggregate as a whole. If you allow altering aggregate's data with any mechanism other then going through the aggregate root you will no longer be sure that it is in a valid state. So if you share tables between 2 aggregates you will loose one of the main advantages that aggregates offers.

And by duplicating the aggregate, the ubiquitous language will be no longer reflected in the code since there is only one aggregate in the real business.

Regarding your example:

Suddently, a new business requirement arises with a new set of invariants on a completely different topic than the first aggregate.

This sounds like it is another bounded context. So I suggest moving the new aggregate to another bounded context but if you are sure it belongs to the same bounded context then don't create a new aggregate. Just add the new business rules to the existing one. Duplicating aggregate is definitely a bad idea.

Upvotes: 5

Related Questions