Search code examples
domain-driven-designrepository-patternddd-repositories

Client in Repository Pattern of DDD


I've been reading a book Domain-Driven Design Quickly.
Now I've reached the Repository Pattern.

I am not sure what are they referring by mentioning the "Client"?
What does "Client" mean here?

Databases are part of the infrastructure. A poor solution is for the client to be aware of the details needed to access a database. For example, the client has to create SQL queries to retrieve the desired data. The database query may return a set of records, exposing even more of its internal details. When many clients have to create objects directly from the database, it turns out that such code is scattered throughout the entire domain.


Solution

  • Client of a repository is a piece of code (another class), usually application layer in context of DDD/Onion Architecture. The rule of a thumb says: 1 repository per Aggregate Root. If your Aggregate Root is Order, which has a collection of OrderItem inside, you create only OrderRepository and return back the whole Order with ALL OrderItems, no Lazy Loading. Now, your client, (application layer code) should have no idea what is inside repository, (is it file based, sql based, http based) you treat it as inmemory collection: repository.GetById(orderId) where repository is IOrderRepository. That would mean you can easily change your repo from in Memory to sql and back anytime and your client code (application layer) or whatever class which uses repository will not be affected hence Liskov Substitution principle is preserved.