An Aggregate should never handle other aggregates directly

An Aggregate's responsibility is only to itself. It's only concern should be about managing invariants within itself and maintaining transactional integrity among its enclosed entities. An Aggregate should never be concerned about changes outside its boundaries, nor should it reach out and perform changes outside itself.

Consequently, Aggregates never load or handle other aggregates directly. To an Aggregate, all other Aggregates are visible as simple identifiers and nothing else.

When an Aggregate is linked to another Aggregate, it only preserves an identifier that establishes the relationship. When other aggregates need to change in response to changes within an Aggregate, they are performed as separate transactions, usually by event handlers that listen to events bubbling up from the aggregate.

Take Order and Customer Aggregates as an example. The Order Aggregate maintains a link to the Customer placing the order in the form of a unique identifier. The relationship is in the form of a simple identifier, not the User object itself.

Let's assume a requirement of sending an email to the customer intimating them that their item is on the way once an order is shipped. The Order is marked as shipped, but it doesn't have the customer's email address to be able to initiate an email. Instead, the Order Aggregate raises an event OrderShipped to tell the rest of the world about the change. We then add Event Handlers that listen to the OrderShipped event, retrieve the user, extract their email address, and initiate an email.

Remember that there is no reason for the user aggregate to be part of the same bounded context as the Order Aggregate. Typically, it is part of an Account or Identity bounded context running as a separate microservice. Domain Events allow us to decouple the User Aggregate completely from the Order Aggregate, allowing the User Aggregate to be designed as optimally as possible.