Search code examples
domain-driven-designaggregateroot

Should AggregateRoot contain collection of other AggregateRoot?

I've read this interesting topic in order to study DDD and found out a new idea that the author said "the argument for not making a ‘ProductReviews’ collection inside the Product class". Because "There are no true invariants between these two entities"

Class diagram

There is no ICollection<ProductReview> inside Product class. Then, the question are

  1. Does it compatible with DDD?
  2. What is advantages and drawbacks when doing that?
Solution

  • Does it compatible with DDD?

    Yes, separating the elements of a logical collection of ProductReviews as aggregates outside of the Product aggregate is compatible with DDD.

    That said, when separating things this way, you wouldn't normally try to insist upon a transactional cascade delete, as shown in the example you linked.

    What is advantages and drawbacks when doing that?

    There are typically two advantages

    If changes to two different parts of the model do not need to be synchronized -- which is to say that you never need to change the two parts together to maintain an invariant -- then modeling those parts as separate aggregates helps to make this separation explicit (and therefore easier to reason about, and so on).

    Breaking a model into separate aggregates supports parallel work means that we can reduce the amount of coordination required to make changes.

    If two different parts of the model are really separated from each other, you can use completely different technologies to store them.

    On the other hand, it has the disadvantage that when you later discover that you have a requirement to coordinate changes to two different aggregates after all, then things get messy. What you really have at that point is a single "logical" aggregate in your data model that has been broken up into multiple aggregates in your domain model with coordinated responsibilities.