one repository for each root aggregate entity in domain driven design

Question

If you follow the repository pattern they... say to create a repository for each root aggregate entity.

That means when I have this model:

customer has orders order has products product has supplier

etc...

That would mean I have 4 repositories which are put into ONE repo. customer is the root entity.

Do I misunderstand here something?

Answer 1

It is correct that you should have a repository per aggregate. What can vary however is the set of aggregates in your domain. The Customer/Order/Product/Supplier model can be decomposed into aggregates in several ways. The decomposition into aggregates depends on a variety of factors and is contingent upon the domain at hand.

An aggregate should be a consistency boundary meaning that it defines what set of entities should be consistent in the context of behaviors associated with those entities. Given this constraint, object references between aggregates should be eliminated and replaced with identity references.

In your model, it could be that customer,order,product and supplier are distinct aggregates and would therefore require separate repositories. Even though customer is an aggregate root (part of the customer aggregate) and order depends on customer, it does not mean that the customer repository should contain the order repository. The order repository should be completely separate, since order is a the root of the order aggregate.

Take a look at Effective Aggregate Design by Vaughn Vernon for in-depth treatment of how to design aggregates.

Answer 2

You have 4 entities related as you've outlined above and the repository implements the transaction context for all of those related entities.