How To Determine Aggregate Root - Domain Driven Design

Question

I have an aggregate: User.
How will I determine its aggregate root?

cause i have:

   +User(folder)
     - User(Abstract Class)
     * Administrator(Concrete inherits from User)
     * Manager(Concrete inherits from User)
     * Maintenance(Concrete inherits from User)

Also do I have to make a repository for each user class(admin, manager, maintenance)? or just make 1 repository which uses the abstract class(User)?

Answer 1

Your question has two, though related parts: First, I think you notions of aggregate and aggregate root are not accurate. Hence, it is important to get them right before moving forward.

When you have an inheritance relationship, this is not an aggregate problem. Aggregate applies to composition. Here is why:

Let's take your own example. You have an abstract class User, and then you have these specializations of User: Administrator, Manager, Maintenance. Now, these four are not in an aggregate-aggregate-root relationship. But, they are all aggregate roots. Or in other words, each is aggregate root.

Starting from the user, let's say this is the aggregate root of an aggregate. Now, because an Administrator is-a User, you can replace a User with an Administrator, and it becomes the root. Same goes with other specilizations.

The key is to understand that Administrator, Manager, Maintenance are replacements for User in the same aggregate. They are not object values of User.

The second part of your question is about implementation. Whether to implement separate repository classes for each sub-type or a single one for all. The answer to this question depends on the particulars of your application, the kind of tools you use etc. There is no hard rule which of the two ways to chose. For example, if your subtypes differ in only few attributes, it may be better to have them all in single table and single repository, otherwise in have separate repositories. For example, the Hibernate Framework, allows either of the two ways and its up to the developer/designer to chose from.

But, again, the key is to think about this problem, as a inheritance (which it is) not an aggregate/aggregate-root problem.