Domain Driven Design: How to handle a conceptually large aggregate root?

Question

I am trying to model a very simple domain which has the conceptual (one)PARENT --> (many)CHILD. The problem being that the number of children in the relationship may be in the millions.

I'm trying to construct an aggregate root that will allow me to "put" (update or insert if doesn't exist) a single child at a time. However, the values being updated must be validated beforehand by the parent.

What patterns can I use to approach this? Currently I have considered the following:

PARENT as aggregate root

• +Validation is simple as children are accessed via parent
• -Non performant as may have to retrieve millions of children in order to update just one
• +/- Can I do lazy loading? I read allot of articles that this is a DDD anti-pattern due to consistency concerns

CHILD as aggregate root

• +Performant as only retrieving the data to update
• -Validation because non trivial, either the parent must be an entity of the root, or the root must be externally provided the parent to do validation. Both options cause issues:
  • Because the update is "put" style, the first option makes creation of the child hard (if I implement creation in the repository's find(id) method, then I don't have the necessary information to construct the child, and if I put it in the service calling the repository then I don't have a way to access the parent information as its not a aggregate root).
  • The second option causes consistency issues, i.e. I could provide a parent that is not a parent of the child being updated.

BOTH as aggregate roots

• +/- How do I ensure consistency, i.e. child is validated by its actual parent?

Answer 1

You haven't understood what an aggregate root (AR) is. It isn't a parent container for children. It's s concept where has should be handled as is defined by . One to many has nothing to do with identifying an AR.

A "child" is a concept that makes sense to exist in AR context i.e it's part of the aggregate represented by the AR. Your example seems to define a repository, a container of items. And it does look a bit like CRUD functionality.

Are you sure you are in an aggregate and not in a context where a simple service is enough?