What's the connection between aggregate roots and has/belongs to relationships?

Question

In trying to learn DDD by applying it to a new project, I've run into an obstacle.

Here's a simplified structure of my very real domain: a project has many components which have many objectives which have many contracts for carrying out said objectives.

Project A
|_Component A
|_Component B
  |_Objective A
    |_Contract A
    |_Contract B

Rule: Each project and contract is allocated some amount of money. Invariant: The sum of all the contracts' funds in a project shouldn't exceed the project's funds.

This suggests that adding new contracts to an objective should be done through the project since it's the only entity that knows how much money it has. In DDD words, to enforce consistency, projects and objectives should be part of the same aggregate, with the project as its root.

However, intuitively, this doesn't make sense. It is objectives that contracts belong to, not projects. They exist first and foremost to help complete objectives and only indirectly projects. "Add a contract to an objective," sounds more natural than, "Add a contract to a project," too, and the code would reflect that: objective.add_contract(new_contract) vs project.add_contract_to_objective(objective, new_contract).

I'm also worried that this design might turn the project into a kind of god object.

Am I conflating aggregates with the has/belongs to relationship, or is my gut feeling onto something? Should I, perhaps, create a service—though I don't know what I'd call it, and I think that's a red flag—that copies the project's funds and passes it to the objective, like objective.add_contract(new_contract, project_funding)?

(On second thought, that sounds like a ticket to the anemic domain model I've heard so much about.)

Answer 1

You can model this more loosely coupled by creating two Aggregates and utilize Domain Events.

Project
    RemainingBudget
    
    OnContractAdded(Contract)
        RemainingBudget.Subtract(Contract.costs)
        RaiseDomainEvent(ProjectBudgetReducedEvent(ProjectId, RemainingBudget))

and

Objective   
    ProjectId
    RemainingProjectBudget  
    List<Contracts>

    OnProjectBudgetReduced(ProjectId, RemainingBudget)
        RemainingProjectBudget = RemainingBudget

    AddContract(Contract)
        if(Contract.Cost > RemainingProjectBudget)
            return Error
        Contracts.Add(Contract)
        RaiseDomainEvent(ContractAdded(Contract))

In the application layer, you will have to add some event handlers and a mechanism to dispatch events when saving changes to an aggregate. That adds a bit of complexity in that layer, but in return you will get a cleaner domain layer without the deep hierarchy.

Answer 2

I would make sure a component and an objective have a reference to their parent. And if they are assigned to another parent, update the parent.

That way an objective can request to the component if it Allowed.

The component can do it’s own business rules plus asking the Project if it’s allowed.

Also when a contract or a component would be moved, they can check again if the new configuration is allowed.

public class Project
{
    List<Component> _Components = new List<Component>();
    
    
    public void Add(Component component)
    {
        _Components.Add( component );
        component.OnAddedToProject(this);
    }
    
    
    public IReadonlyList<Component> Components => _Components;
}


public class Component
{
    public Project Project { get; private set; }


    OnAddedToProject(Project project)
    {
        Project = project;
        
        if ( !IsValid )
            throw new Exception();
    }
    
    
    public void IsValid
    {
        get
        {
            if ( !Project.IsValid )
                return false;
                
            if ( !OtherConstraint )
                return false;
                
            return true;
        }       
    }
}