Domain-Driven Design: how to model nested product category hierarchy? Even worse, what if the product category is an Aggregate Root?

Question

I am practicing Domain-Driven Design so why not build a demo product catalog project? Apparently Product is the Core Domain here, but since I like to make the project more interesting, I would love to support nested Category hierarchy. In other words, a Category could have many child Category.

Moreover, I would want to separate Category from Product domain and make it its own Supporting Domain.

Question: Marking Category as AggregateRoot doesn't sound right to me. A Category could have many child Category, which are also AggregateRoots?!! How can I go about modeling this? Nested product category is pretty common in E-Commerce real life situation.

---

namespace DL.Demo.Domain.Shared

public abstract class ValueObjectBase<T> : IEquatable<T> 
    where T : ValueObjectBase<T>
{
    public abstract bool Equals(T other);
    public abstract override bool Equals(object obj);
    public abstract override int GetHashCode();
}

public abstract class EntityBase : IEquatable<EntityBase>
{
    public Guid Id { get; private set; }

    protected EntityBase()
    {
        this.Id = Guid.NewGuid();
    }

    // Some Object overrides
}

And I actually have AggregateRoot inherents from Entity because I guess only an Entity could be an AggregateRoot?

public abstract class AggregateRoot : EntityBase
{
}

---

namespace DL.Demo.Domain.Catalog

public class Category : AggregateRoot
{
    public string Name { get; private set; }
    public Guid? ParentCategoryId { get; private set; }
    public CategoryStatus CategoryStatus { get; private set; }
}

Having a nested list of AggregateRoot just doesn't sound right to me. If you don't mark the Category as the AggregateRoot, how would you go about modeling this?

I am new to DDD and all other related cool stuff like Domain Events, Event Sourcing, etc. I will be appreciated if somebody who had experience can tell me if I am going to the right way.

Answer 1

I am new to DDD and all other related cool stuff like Domain Events, Event Sourcing, etc. I will be appreciated if somebody who had experience can tell me if I am going to the right way.

You are on the right way.

Category should be an Aggregate root, with a reference to parent category by it's ID and this is very good.

Nested categories are a good candidate for event-sourcing, even if there are no special invariants to protect because of the different modes that this hierarchy could be projected in the Read models. You are not limited in any way on that representation, although the Aggregate is straight-forward. In every used Read model you could implement them differently as:

1. Model Tree Structures with Parent References
2. Model Tree Structures with Child References
3. Model Tree Structures with an Array of Ancestors
4. Model Tree Structures with Materialized Paths
5. Model Tree Structures with Nested Sets

See more here about implementing tree structures (this link points to MongoDB but that is not relevant).

The Category Aggregate just emits simple events as ACategoryWasCreated, ACategoryHasMovedToOtherParent and so on and the Read models just adapt to reflect those events.

I've implemented a tree structure like this and the queries on the read-side (the query side) are very very fast. You could select the products in a category and all child categories with no joins. Or you could build a category path, again, with no joins.

Answer 2

The key to defining an aggregate is to define first a transactional boundary. Outside of an aggregate boundary consistency is eventual - achieved by reacting to the domain events emitted by an aggregate.

Aggregate can hold another aggregate ID (Value Object) as a reference, however, is not responsible to be transactionally consistent with another aggregate.

So, the main question - Is your tree transactionally consistent? If yes, linked list won't scale well. You have to model it differently.

Modeling is context specific and is not cookie-cutter exercise. Maybe your category is just a value object that could be modeled as a path. Hard to say without broader context.

Answer 3

If you want to have a category tree, then the tree itself should probably be your aggregate root (I see you were coming to this conclusion on your own in the comments already). And this would have functions to add or remove children and so on.

And yes, with very large trees you could probably gain a lot of performance in having a read-only projection of your tree in for instance json format (stored in MongoDb, cache, file or whatever). Especially considering how such a category tree is typically updated only a tiny fraction of how often it is read, you could also easily get away with always just maintaining that json and foregoing a normalised database table tree altogether.