Domain Driven Design - Aggregate Root and Nested Aggregate Invariants

Question

I've come to a bit of an impasse with the best way to implement a DDD problem, and am hoping for some advice from those with more experience, please.

I have a RecipeCollection, which has a collection of type Recipe (as you might expect). The abbreviated code looks like this:

public class RecipeCollection : IEntity<RecipeCollectionId>, IAggregateRoot
{
    private readonly RecipeCollectionId id = new();
    private readonly List<RecipeId> recipeIds = new();

    public void AddRecipe(RecipeId recipeId) { /* not sure what to do here! */ }
...
}

public class Recipe : IEntity<RecipId>
{
    public readonly string Name { get; private set; }
...
}

One of the business rules is that a Recipe cannot have the same Name within a RecipeCollection. The obvious place to enforce this invariant is within RecipeCollection, when adding a new Recipe. However, RecipeCollection only holds a list of RecipeId, not a list of Recipe itself.

Ideally, RecipeCollection would hold a collection of Recipe, which would make checking for duplicate Recipe.Name easy. However, RecipeCollection holds a collection of RecipeId. It does this to avoid potential problems such as loading a RecipeCollection from memory, which loads all its Recipes, which each in turn load another collection, and so on, and before you know it, you've loaded the entire database. I know I could use lazy loading, but I may use a data store where this isn't possible, so I'm forced to hold a collection of RecipeId.

Is the best solution, in this case, to have the calling code, i.e. the command handler that retrieves the RecipeCollection from the repo, check there are no duplicated Recipe Names before adding the Recipe? This would leak the business logic out of the Aggregate root in this instance, which is why I haven't committed to this solution. Or is there another solution/pattern I'm missing?

Answer 1

Purely technically the obvious best solution is to let the database figure this out. Assuming there is a database and the number of recipes is unbounded, so we don't want to load all into memory or iterate every one. The database can probably already do this and probably much better.

If that is true, then we just have to figure out where the call should be. If it is up to the caller to do it, then obviously this logic is not encapsulated. Can be forgotten, duplicated, made poorly, etc.

I would expect it to be in AddRecipe(). It seemingly implements some use-case, so I would except it does everything necessary to fulfill it.

Answer 2

Or is there another solution/pattern I'm missing?

You can push this problem out to the DB. But now your solution is dependent on the DB. And maybe that's fine. But there are alternatives.

I'm forced to hold a collection of RecipeId.

Remember, references are tiny. Doesn't matter how big your recipe object is you can copy references to it into many data structures and still only have one copy of the recipe loaded into memory.

Which means just because you have a collection of RecipeIds that may have duplicates doesn't mean that's the only collection you can have. Create Recipes and never let it get loaded or added to without validating. You can still have your other collection that doesn't check for whatever technical reason. But if Recipes is populated you know it's validated. You know there are no duplicate names in it.

With this approach you are free to store your recipes in text files because the bulk of your code doesn't know or care if there is the DB.

Answer 3

It will be very useful if you examine the following sample design that Microsoft has given as best practice.

eShopOnContainers Github Repo

Note the relationship between the Order and OrderItem tables.