2

I'm new to DDD and I'm trying to figure out the aggregate root. I'm sure this question has been asked a million times.

So I have :

  • Products (thousands)
  • Catalogs (hundreds)
  • CatalogEntries that associate a product to a catalog and a price (prices are different depending on the catalog)

A catalog can exist without a product and a product can exist without a catalog so I have at least 2 aggregates:

  • Product
  • Catalog

But where does CatalogEntries go ? If I delete a catalog I need to delete all it's entries but if I delete a product I need to delete all entries from this product too.

If product is the aggregate and I delete a catalog, I need load all my products to remove it and if Catalog is the aggregate I need to load all my catalogs to remove it. I doesn't make sense.

So is it a good idea to have ProductEntry as an aggregate root ? But it can't really live without a product or a catalog, what I thought was the goal of an aggregate.

2
  • You have not provided enough information to synthesize an answer to your question. Does Product need to be aware of it's Catalog or visa versa in order to enforce business rules? As it stands the behavior you intend to model is trivial and needn't belong on either Product or Catalog. Simply adding an additional aggregate (Inventory) with simple methods like Inventory.Add(productId, catalogId, price), Inventory.RemoveProduct(productId), and Inventory.RemoveCatalog(catalogId) seems like a straightforward solution. Feb 19, 2019 at 18:59
  • @king-side-slideThat's exactly what I did.
    – Mike
    Feb 19, 2019 at 20:12

1 Answer 1

1

Note: specifically relating to delete, you may want to review Don't Delete -- Just Don't.

But where does CatalogEntries go ? If I delete a catalog I need to delete all it's entries but if I delete a product I need to delete all entries from this product too.

An important element is time: do you need to delete all of the catalog entries that refer to the product at once, or could the catalog items be removed, say, a minute or two later?

If it has to be done at once -- meaning that the business would be exposed to a lot of liability if the products and catalogs were ever out of sync, then you need to have a big aggregate around the entire mess.

If, as is more likely, it's OK for the catalog and products to be out of sync, because the company can apologize, then you should expect them to be two separate aggregates.

For reference, see Pat Helland on Memory, Guesses and Apologies, or Adrian Colyer on The Data Crisis.

I'm new to DDD and I'm trying to figure out the aggregate root.

Finding aggregate root boundaries is really hard when all your system does is remember information from the outside world. It might be easier to start with a system that makes decisions on its own using the information provided.

1
  • Really good article, I was aware but it's a fresh reminder.
    – Mike
    Feb 15, 2019 at 21:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.