Hierarchy with event sourcing

Question

Could anyone offer any advice on how they would organise entities, aggregate roots, etc in a hierarchical domain model when using event sourcing?

A project has assets. Assets are a hierarchy. Each asset has a set of data (level contains a set of category, category contains a set of item, etc). There could be 100,000s of assets and they in turn could have 10,000s of sub items.

• project (id)
  • assets (id, parentId)
    • level
      • category
        • item
          • case
  • revenues
  • other...

From my understanding of DDD there would be one aggregate with project being the aggregate root because level cant exist without assets and assets cant exist without projects, etc.

This would lead to there being an enormous amount of objects in the project. It would also mean that to add a case I would have to have a method on the root such as CreateNewCase(asset, level, category, item, case) or CreateNewCase(itemId, case) if each item had a unique key. Project would end up enormous and contain methods for handling events for almost all the entities in the application.

Any help would be appreciated.

Answer 1

In my project I have the concept of the model(actor) and since I use event sourcing in json format all the models inside this model are considered components. If you want to see a practical example look the examples of this project. https://github.com/politrons/Scalaydrated

Answer 2

DDD is all about mindset and in this case you're using the wrong mindset. Project, asset, item, category etc are concepts known and used by the Domain. An aggregate usually defines a concept or an use case of one. Event sourcing is just an implementation detail: you mutate state by applying events and those events are also how an aggregate is persisted.

But, before you get to that you need to properly identify the aggregate and its root. This is a matter of design unrelated to programming language, library, framework or actual implementation (like event sourcing).

So, you have to really understand the concepts used by the domain and their use cases. Every time you read/hear: 'X has Y', check to see if the meaning is in fact 'X is defined by Y' or 'X acts as a grouping criteria for Y'. Nobody here can tell you the design for your app, we can only tell you some principles and some gotchas but that's it. There's no formula, recipe or 'best practices', it's only understanding the Domain and then modeling it using code.

You will never get a generic DDD solution for your specific problem, because in DDD each solution is highly dependent on your problem. And the sooner you understand that DDD is a paradigm and not a 'how to' magic recipe, the better you'll be. Else, you'll waste years doing everything BUT DDD, regardless of how many classes named aggregate root, repository and entity you'll have.

Answer 3

You pretty much answered your own question -- this model is impractical, and will be slow as you need to load tens of thousands of items each time you rehydrate an aggregate root from the database (unless resorting to complex lazy loading).

The "can't exist without" rule is rarely applicable. I suggest you read the aggregate design recommendations here : http://dddcommunity.org/library/vernon_2011/ http://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577