CODEWITHSUNDEEP
design-patternstreedomain-driven-designentitycqrs
SystematicFrank
SystematicFrank

Reputation: 17251

Domain Aggregate Root with tree of Entities

One property of my aggregate root Node is a tree like group of entities Task. Like

- Node
    - Name
    - Release
    - User
    - task
       - task
       - task
            - task
       - task

The tree of Task can be awfully large and therefore, not loaded completely into memory. I could implement some type of object lazy loading or dynamic queries. Furthermore I will need an easy way to add new tasks with a function like Task::addSubtask... but my intuition is telling me that those solutions are wrong in so many levels.

I am trying to take some lessons about DDD from this problem. So I would like to find a confirmation to these assumptions.

  1. Any aggregate root should always be fully loaded. Any partial load will require a subcomponent to be able to perform a query (through a repo, stored query...) which would brake many rules: single responsibility, ignorance of persistance mechanisms... (NOTE: I do not have an ORM layer providing lazy loading by default)

  2. The "tree shape" of tasks in memory is actually only necessary for the Outline view in the GUI. Therefore I should have a dummy composite which can perform queries to the Service Layer of my Domain Model.

  3. Since there is no reason to have a Task outside the context of a Node, my node repository should deal with any operation requiring the tree exploration, like:

    (List*) findChildrenOfTask(Task* aTask)

    (List*) findChildrenOfTask(Task* aTask, String regexInText)

    (void) addChildToTask(Task* aTask)

These are my assumptions, but I would like to confirm them with someone with more experience doing DDD. The "tree only in the GUI" also seems to spur some ideas of CQRS ideas. Is this problem one example of the benefits adopting CQRS for DDD?

Upvotes: 2

Views: 2157

Answers (1)

Mgetz
Mgetz

Reputation: 5128

This exact example is actually addressed in Vaughn Vernon's book Implementing Domain Driven Design

That said I invite you to ponder the following:

  • Does task need to be transactionally consistent with Node? If not it can be its own Aggregate which dramatically simplifies things. Remember that you're thinking about this from the perspective of a command ONLY.
  • If the tree is only for a query why not have a DTO worry about that instead of compromising your domain model?

I will fully admit that Vernon does a MUCH better job of explaining this than I do.

Upvotes: 5

Related Questions