Aggregate Root complexity in Domain-Driven Design

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 hierarc开发者_如何学Pythonhy?

---

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.

---

Like lulian says I guess there is no rules that says how your AR's should look like. If your AR with ObjectA, B and C belong to same business context its fine. But I think you should also reflect on how your clients/use cases are using your model. If you always want the ObjectC's and the object graph traversal from ObjectA and B down to C feels like an unnecessary traversal, maybe your model is incorrect.

If your root object is ObjectA and you have a ObjectARepository you can always add repository methods like GetObjectCsByObjectA(ObjectA objectA) that will list all C's for an A. If a ObjectC can be child to several ObjectB that above solution maybe isn't the best one since you get all C's for one A.

Must most important is how your GUI/clients will use this AR (repeat myself...) You can add extension methods for adding Linq filters or searches to ease the traversal from A to C. Not my favorite but it works. Better can be to try to wrapp ObjectB's collection in ObjectA with either a Value Object or just a simple listwrapper class that is not persisted and is just created when accessing this collection. This wrapper can provide the necessary access methods that suits your GUI and also validations when adding, replacing and deleting list items. The wrapper will be a shortcut for your clients so they do not need to bother how AR is built up inside AR.

Do ObjectB and ObjectC has any associations to other entities outside this AR?