Java – DDD and Validation of Aggregate Root

I believe Eric Evans wrote, "Models are neither right nor wrong; they are simply more or less useful". The question is, which model helps you solve the problem in a clean way. By just referring to the names of a number of classes, it is impossible for others to determine which model would help you solve your problem.

But as to the why should you choose one model over the other:

If one entity (A) does not make sense to load outside the context of a different entity (B), then entity A should probably be aggregated inside entity B. Also, nobody should reference A in this case.

Just because there is a relationship between your entities doesn't necessarily mean that they should be aggregated.

As an example on an aggregate, I once worked at writing an online job site. One of the features was that a person to create a CV, and companies could search for CVs. A CV would contain a list of competencies (A competency in this context mean something like, "I am higly skilled in .NET. I have used it for 12 years, last in 2012). It does not make sense to load a competency in itself. In only makes sense in the context of a CV. Though you could search for CVs matching certain competency requirements, the result would not be a list of competencies, but a list of CVs meeting the required competencies. So in this example, the CV was an aggregate root.

But are terms like 'Application Group', 'Application', and 'Configuration' really part of your domain, or is it part of your infrastructure? I'm not saying that they couldn't. Depend of course entirely on the nature of the application you are working on. But it does sound a lot like system infrastructure in my ears.

This is a common issue when implementing aggregates. It usually gives rise to separating aggregate state onto a another object. That object can be a pure data bucket with public getters/setters for convenience. Outside callers could be aware of the aggregate's state class, but it remains private to the aggregate (as a private field, for instance). The repository could directly load aggregate's state, which can be passed as a single object to the aggregate's constructor.

You would have:

public CustomerState
{
    public Guid Id { get; set; }
    public string ShortName { get; set; }
    public string LegalName { get; set; }
    public TaxCode TaxCode { get; set; }
    public ContactInfo PrimaryContact { get; set; }
    public List<Requisitions> Requisitions { get; set; }
}

public Customer
{
    private readonly CustomerState _state;
    private readonly IDomainEvents _events;

    public Customer(CustomerState state, IDomainEvents events) 
    {
        _state = state;
        _events = events;
    }
}

...

public Requisition OpenRequisition(RequisitionDefinition definition, User requestedBy) 
{
    Requisition req = ... // create the new requisition somehow
    _state.Requisitions.Add(req);
    _events.Invoke(new RequisitionCreatedEvent(this, req));

    return req;
}

Notice that I placed IDomainEvents in the aggregate instead of the state class, because it has some behavior (likely dispatching). For your state object, you only want pure data.

In a very surface way, this organizationally resembles an Anemic Domain Model because the state is separated, and the aggregate essentially just contains methods, similar to a Facade pattern. But the difference being that an anemic domain allows the user to directly manipulate state and run a Transaction Script on their manipulations. But with this, user is not allowed to directly manipulate state... we retain control of validated state changes through domain methods, but add easier loading (and saving).

Now, separating the state in this way does present it's own challenges. Usually naming confusion is one initially. You probably don't want to name your data table CustomerState (and it's probably already named Customer). But naming the table Customer will result in confusion when the aggregate of the same name is structurally dissimilar. If you're up for some reorganization, you might consider naming your aggregate Sales or Ordering or the like (based on what area it deals with) and keep the customer's state named as Customer. You might find that leads to better organizational clarity for your use cases anyway.