Aggregate Root complexity in Domain-Driven Design

Question

Where does one draw the line in the complexity of an aggregate? To clarify, if my aggregate has a list of ObjectA which has a list of ObjectB which has a list of ObjectC, should my aggregate be responsible for retrieving ObjectC? Or should I be looking at creating another aggregate to keep this complexity down to a couple of levels in the hierarchy?

Answer 1

In most cases the boundaries of the Aggregate should be the consistency boundaries needed for your model. That means that if changes to ObjectA or B or C need to be consistent with each other than they probably belong to the same Aggregate.

The complexity ( business logic complexity ) should be handled by identifying all the concepts in the domain and splitting the behavior across the entities/VOs involved.

The object retrieving complexity (infrastructure complexity) should be handled by the infrastructure and not by the aggregate.

In conclusion model you ARs according to your domain and to your consistency boundaries and not to facilitate infrastructure concerns.