CODEWITHSUNDEEP
domain-driven-designaggregateroot
frol
frol

Reputation: 185

DDD: solution for references to a non aggregate root

I have two aggregate roots and two non aggregate root entities:

entity relationships

I know, that the relation D -> B breaks DDD principle.

I heard, that in the most cases the solution is to make the referenced entity a new aggregate root.

But is making B to a new aggregate root really an option if B is a real child of A (B can not live without A)?

Upvotes: 13

Views: 2149

Answers (2)

MikeSW
MikeSW

Reputation: 16378

First of all, this isn't DDD thinking, this is RDBMS thinking. In DDD you model business processes as they are in the real world, you don't have one-to-many etc concepts. So forget about DB, foreign keys and so on.

What are your bounded contexts (BC)? Each aggregate is a BC itself so they can have different representation of the concepts EVEN if they are named the same.

If I understand corerctly, it seems that A B C D are part of a single aggregate. That doesn't mean they are defined ONLY in that aggregate and ONLY in that form. However if C is a fully fledged AR in some other BC, it is quite possible that in THIS context to be represented only as an id or a few properties (interfaces are VERY handy for this stuff). So even if they are both named C, they are different, having only the behavior needed by a specific context.

DDD works with a lot of BCs and the models are valid for one BC only. this means that in your app you would have multiple A ,B ,C definitions according to each BC and each definition might be slightly different. This means that there isn't really only one model suitable for all the cases (and I'm not talking about CQRS here, just DDD).

I don't know much about the domain to actually come up with something more concrete. But simply put, try to represent things as they are and as they work in reality.

Upvotes: 1

guillaume31
guillaume31

Reputation: 14080

I agree with you, sometimes it just doesn't make sense to separate one entity from its aggregate, because it fits so naturally in it. This is one of the reasons why I'm not totally sold on the "small aggregates" approach that some recommend.

In such a case, what you can do is get a reference to B by traversal of an instance of A instead of getting it directly. After all, if B can't exist without A, there's no reason objects outside of the aggregate should know about a particular B and not know about its A.

Upvotes: 2

Related Questions