DDD: Large Aggregate Root - Person

Question

I am building a system to manage person information. I have an ever growing aggregate root called Person. It now has hundreds of related objects, name, addresses, skills, absences, etc. My concern is that the Person AR is both breaking SRP and will create performance problems as more and more things (esp collections) get added to it.

I cannot see how with DDD to break this down into smaller objects. Taking the example of Absences. The Person has a collection of absence records (startdate, enddate, reason). These are currently managed through the Person (BookAbsence, ChangeAbsence, CancelAbsence). When adding absences I need to validate against all other absences, so I need an object which has access to the other absences in order to do this validation.

Am I missing something here? Is there another AR I have not identified? In the past I would have done this via an "AbsenceManager" service, but would like to do it using DDD.

I am fairly new to DDD, so maybe I am missing something.

Many Thanks....

Answer 1

The Absence chould be modeled as an aggregate. An AbsenceFactory is reposible for validating against other Absence s when you want to add a new Absence.

Code example:

public class AbsenceFactory {
    private AbsenceRepository absenceRepository;
    public Absence newAbsenceOf(Person person) {
         List<Absence> current = 
              absenceRepository.findAll(person.getIdentifier());
         //validate and return
    }
}

You can find this pattern in the blue book (section 6.2 Factory if I'm not mistaken)

In other "modify" cases, you could introduce a Specification

public class SomeAbsenceSpecification {
    private AbsenceRepository absenceRepository;

    public SomeAbsenceSpecification(AbsenceRepository absenceRepository) {
        this.absenceRepository=absenceRepository;
    } 

    public boolean isSatisfiedBy(Absence absence) {
          List<Absence> current = 
              absenceRepository.findAll(absence.getPersonIdentifier());
         //validate and return
    }
}

You can find this pattern in the blue book(section 9.2.3 Specification)

Answer 2

This is indeed what makes aggregate design so tricky. Ownership does not necessarily mean aggregation. One needs to understand the domain to be able to give a proper answer so we'll go with the good ol' Order example. A Customer would not have a collection of Order objects. The simplest rule is to think about deleting an AR. Those objects that could make sense in the absence of the AR probably do not belong on the AR. A Customer may very well have a collection of ActiveOrder objects, though. Of course there would be an invariant stating that a customer cannot be deleted if it has active orders.

Another thing to look out for is a bloated bounded context. It is conceivable that you could have one or more bounded contexts that have not been identified leading to a situation where you have an AR doing too much.

So in your case you may very well still be interested in the Absence should the Customer be deleted. In the case of an OrderLine it has no meaning without its Order. So no lifecycle of its own.

Hope that helps ever so slightly.

Answer 3

I am building a system to manage person information.

Are you sure that a simple CRUD application that edit/query RDBMS's tables via SQL, wouldn't be a cheaper approach?

If you can express the most of the business rules in term of data relations and table operations, you shouln't use DDD at all.

I have an ever growing aggregate root called Person.

If you actually have complex business rules, an ever growing aggregate is often a syntom of undefined (or wrongly defined) context boundaries.