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.

  • 2
    There have been many, many questions lately about how to communicate between entities in DDD. None of them have satisfactory resolutions because DDD is not a development technique; it is a design technique. Solve this problem in the usual way. Let DDD inform your design, not your architecture. Commented Jun 24, 2021 at 13:55

1 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.

  • Thanks! This completely answered my question and my understanding about the topic.
    – Jesse
    Commented Jun 24, 2021 at 18:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.