When two Entities don't form an Aggregate but are related, the best option to have Entities reference one another is by using Identities. Identities were already explained in the Chapter 4, Entities.

Consider a User and their Orders, and assume we haven't found any true invariant. User and Order wouldn't be part of the same Aggregate. If you need to know which User owns a specific Order, you can probably ask the Order what its UserId is. UserId is a Value Object that holds the User Identity. We get the whole User by using its Repository, the UserRepository. This code generally lives in the Application Service.

As a general explanation, each Aggregate has its own Repository. If you've fetched a specific Aggregate and you need to fetch another related Aggregate, you'll do it in your Application Services or Domain Services. The Application Service will depend on Repositories to fetch the Aggregates needed.

Jumping from one Aggregate to another is what's generally called traversing or navigating your Domain. With ORMs, it's easy to do it by mapping all the relations between your Entities. However, it's also really dangerous, as you can easily end up running countless queries in a specific feature. As a rule, you shouldn't do this. Don't map all the relations between your Entities because you can. Instead, only map the relations between Entities inside an Aggregate in your ORM if two Entities form an Aggregate. If this isn't the case, you'll use Repositories to get referenced Aggregates.