Question

Two months ago I bought the book “Professional ASP.NET Design Patterns” by Scott Millet because I wanted to learn how to build a layered web application using design patterns. I used the case study from this book in my own application so everything is set up.

The problem I have is that I am not sure about my aggregate roots.

I have a user that can create collections. A user can add categories to a collection and keywords to the categories. It looks like this in my database:

- Users
    - PK: UserId

- Collections
    - PK: CollectionId
    - FK: UserId

- Categories
    - PK: CategoryId
    - FK: CollectionId

- Keywords
    - PK: KeywordId
    - FK: CategoryId

I don’t find it logical to make user the aggregate root of collection, but categories and keywords together form a collection. So I made user an aggregate root which has no children yet, and collections an aggregate root. A single collection can have multiple categories and categories can have multiple keywords. So when I want to add a category I do this:

public void CreateCategory(CreateCategoryRequest request)
    {
        Collection collection = _collectionRepository.FindCollection(request.IdentityToken, request.CollectionName);

        Category category = new Category { Collection = collection, CategoryName = request.CategoryName };

        ThrowExceptionIfCategoryIsInvalid(category);

        collection.AddCategory(category);

        _collectionRepository.Add(collection);
        _uow.Commit();
    }

Which works perfectly fine, but when I want to add a keyword I first need to get the collection and then get the category where I can add a keyword to and then commit the collection:

public void CreateKeyword(CreateKeywordRequest request)
    {
        Collection collection = _collectionRepository.FindCollection(request.IdentityToken, request.CollectionName);

        Category category = collection.Categories.Where(c => c.CategoryName == request.CategoryName).FirstOrDefault();

        Keyword keyword = new Keyword { Category = category, KeywordName = request.KeywordName, Description = request.KeywordDescription };

        category.AddKeyword(keyword);

        _collectionRepository.Add(collection);
        _uow.Commit();
    }

And this just don’t feel right (is it?) what made me believe that I should maybe make category the aggregate root of keyword. But that raises another question: is it still valid that I have a collection aggregate which creates a category aggregate like I did in my first code example? Example: collection.Add(category);

Answer 1

An aggregate root can certainly contain nested children, however if those children are also aggregates that may be a warning that perhaps the aggregate is doing too much. In your case, I think Collection is an aggregate and Category is not, it is just an entity or even a value object belonging to the Collection aggregate and it happens to contain Keyword instances which are also value objects.

I would change the implementation so that the CreateCategory service method looks more like this:

public void CreateCategory(CreateCategoryRequest request)
{
        var collection = _collectionRepository.Get(request.IdentityToken, request.CollectionName);

        collection.AddCategory(request.CategoryName);

        _uow.Commit();
}

The AddCategory method on the Collection is responsible for creating the Category instance as well as error checking. This makes sense because it is the aggregate root and it is responsible for managing the cluster of entities and value objects it contains. There is no call to the Add method on the repository because the ambient unit of work should commit the changes.

The CreateKeyword method I would change to look more like:

public void CreateKeyword(CreateKeywordRequest request)
{
        var collection = _collectionRepository.Get(request.IdentityToken, request.CollectionName);

        collection.AddKeyword(request.CategoryName, request.KeywordName, request.KeywordDescription);

        _uow.Commit();
}

The AddKeyword method on Collection retrieves the appropriate Category and then adds a keyword to it, throwing exceptions if needed to enforce consistency and validity.

As you can see, there is a pattern to these two methods – first an aggregate is retrieved by a key, then a method on the aggregate is invoked, and finally everything is committed. In this way, the aggregates have more control over their own state and you avoid having an anemic domain model as well as reducing the amount of code present in services.

For an in depth treatment of aggregate design, take a look at Effective Aggregate Design by Vaughn Vernon.