Aggregate Root references other aggregate roots

Question

I'm currently working a lot with DDD, and I'm facing a problem when loading/operating on aggregate roots from other aggregate roots.

For each aggregate root in my model, I also have a repository. The repository is responsible for handling persistence operations for the root.

Let's say that I have two aggregate roots, with some members (entities and value objects).

AggregateRoot1 and AggregateRoot2.

AggregateRoot1 has an entity member which references AggregateRoot2.

When I load AggregateRoot1, should I load AggregateRoot2 as well?
Should the repository for AggregateRoot2 be responsible for this?
If so, is it okay for the entity in AggregateRoot1 to call the repository of AggregateRoot2 for loading?

Also, when I create an association between the entity in AggregateRoot1 to AggregateRoot2, should that be done through the entity, or through the repository for AggregateRoot2?

Hope my question makes sense.

[EDIT]

CURRENT SOLUTION

With help from Twith2Sugars I've come up with the following solution:

As described in the question, an aggregate root can have children that have references to other roots. When assigning root2 to one of the members of root1, the repository for root1 will be responsible for detecting this change, and delegating this to the repository for root2.

public void SomeMethod()
{
    AggregateRoot1 root1 = AggregateRoot1Repository.GetById("someIdentification");
    root1.EntityMember1.AggregateRoot2 = new AggregateRoot2();
    AggregateRoot1Repository.Update(root1);
}

public class AggregateRoot1Repository
{
    public static void Update(AggregateRoot1 root1)
    {
        //Implement some mechanism to detect changes to referenced roots
        AggregateRoot2Repository.HandleReference(root1.EntityMember1, root1.EntityMember1.AggregateRoot2)
    }
}

This is just a simple example, no Law of Demeter or other best principles/practices included :-)

Further comments appreciated.

Personally I can see this current approach getting messy and I think DavidMasters84’s solution is more of an elegant solution. Ie keeping references as id's and extracting this type of domain logic to a domain service. — Chris Moutray
Messy is a good adjective for this approach. I'm allowed to say that because I originally tried implementing this problem in the same way, and a mess is what I found myself in :) you might want to read suggestions here also for a similar question: stackoverflow.com/questions/2118088/… — David Masters
I hear you, but isn't repositories there to manage aggregate roots, and with some good will, relations between roots. And domain Services to handle behaviour that dosen't natural fit in a single entity? Seems to me that making the Domain Service resposible for handling references between roots is the wrong place when reading the definition of a Domain Service... I could be wrong, so a more backed up argument would be appreciated, thanks. — tschmuck
My suggestion for a domain service isn't there to manage references between aggregates; it's there to invoke functionality that involves more than one aggregate i.e. "behaviour that doesn't naturally fit in a single entity". In most models all aggregates relate to each other in some form in terms of a relational databases, the point of aggregates is to break up this dependency graph into manageable groups. If you maintained the relationships between all aggregates in the model it would defy the point of aggregates. — David Masters
Yep that's pretty much my thoughts on it; your question is about running operations between aggregate roots which I think is where the domain service fits in. I think soon you'll be asking yourself how deep does the rabbit hole go... — Chris Moutray

David Masters David Masters · Accepted Answer · 2011-02-07T13:57:52

I've been in this situation myself and came to a conclusion that it's too much of a head ache to make child aggregates work in an elegant way. Instead, I'd consider whether you actually need to reference the second aggregate as child of the first. It makes life much easier if you just keep a reference of the aggregate's ID rather than the actual aggregate itself. Then, if there is domain logic that involves both aggregates this can be extracted to a domain service and look something like this:

public class DomainService
{
    private readonly IAggregate1Repository _aggregate1Repository;
    private readonly IAggregate2Repository _aggregate2Repository;

    public void DoSomething(Guid aggregateID)
    {
        Aggregate1 agg1 = _aggregate1Repository.Get(aggregateID);
        Aggregate2 agg2 = _aggregate2Repository.Get(agg1.Aggregate2ID);

        agg1.DoSomething(agg2);
    }
}

EDIT:

I REALLY recommend these articles on the subject: https://vaughnvernon.co/?p=838

Aggregate Root references other aggregate roots

3 Answers