views:

84

answers:

1

When applying Domain Driven Design to a project, how do you identify the Aggregate Roots?

For example, in a standard E-Commerce website, you might say that the Order is one, and the User is the other. But what if your Users belong to a Company? Does that make your Company the aggregate root?

I'm interested in hearing people's approaches to working out the Aggregate roots, and how to identify poorly chosen aggregate roots.

+3  A: 

One good way of identifying the aggregate root is to use the "delete" test. In your domain if you delete the root, what is deleted with it? This way you can identify domain object ownership, which is a trait of Aggregates.

Also Aggregates create consistency boundaries, so your root, should "hide" aggregated elements from the rest of the object graph and also check their consistency and invariants which should hold. Object inside the Aggregate hold references only to the root (not each other). So if you find someting like this in your domain model, it might suggest you have an Aggregate root.

Gabriel Ščerbák
Right, so I have a User entity that can perform a set of actions, like making sales, updating their profile, e.t.c. It seems like that User would be a root aggregate. However, a Company has a set of users. Deleting a company would delete the users. Does that make a Company the aggregate root, or are they both aggregate roots?!
Robert
@Robert You do not have to use Aggregate for every multiple association, you can use e.g. Composite as well. It is up to you what fits your need best. Aggregates are used to simplify your domain model, but you do not have to use it.
Gabriel Ščerbák