DDD Aggregate reference differences

Question

I've been reading about DDD a lot lately and something I can't find too much about is the following scenario:

Let's say we have a Customer aggregate root and a Contract aggregate root. The reason they are both aggregate roots could be that contract could be accessed directly. A contract expects a Customer in the Create method to be valid, since it cannot exist without a customer.

However, there's two possibilities:

1. Save the CustomerId on the Contract
2. Save a list on the Customer with all the ContractId references for that given customer

Are both of these correct? If so, what's the main difference and when to choose one above the other?

When downvoting: please comment on what is wrong with this question instead of being silent.

Answer 1

In your business domain, if Contract itself is used as frequently as Customer I think it is a hint that you should make Contract an Aggregate root as the same first class citizen as Customer. At the same time, don't let Contract leak into Customer Aggreate root.

Here is my argument:

1. Unless it is an embeded relatioship between the Aggregate root and an Entity, we should avoid introduce One-To-Many relationship. It is my peronsal preference to avoid complexity but I think it is a good practice it Keep It Simple and Stupid. E.g. Order can be an aggregate root and Order Items are encapsulated inside it as a collection.

2. In real world, when users are working on a Contract, it is highly possible Customer being referenced and users can always find Contracts with customer identity.

   But on the contrary, there must be many cases when users are working on Customer mangement but they don't have any interest on Contracts belong to that Customer. This nature of the business makes Customer an essential knowledge a Contract must know but the opposite is not true.

3. As you pointed out a Contract cannot be created without the existing of a Customer. If you make Contract encapsulated inside Customer, it creates a circular reference which could be a problem when you try to create a Customer and Contracts in one shot (Technically: One Transaction). Some modern ORM frameworks can solve the issue, but from a DDD perpective it not good to let implementation details from lower level infrastructure layer leak into your domain model although it is implicit.

   Why should a domain designer think about how Hibernate handles the creation of circular referenced entities? What if you migrate the persistence layer into JDBC, Object Database, etc.? your application could crash or you have to study if the new technology can handle circular reference well.