Edition 0 Updated to asp. Net core 0

The Repository pattern 
The Repository pattern is a Domain-Driven Design pattern intended to keep persistence concerns 
outside of the system’s domain model. One or more persistence abstractions 
- interfaces - are defined 
in the domain model, and these abstractions have implementations in the form of persistence-specific 
adapters defined elsewhere in the application. 
Repository implementations are classes that encapsulate the logic required to access data sources. 
They centralize common data access functionality, providing better maintainability and decoupling 
the infrastructure or technology used to access databases from the domain model. If you use an 
Object-Relational Mapper (ORM) like Entity Framework, the code that must be implemented is 
simplified, thanks to LINQ and strong typing. This lets you focus on the data persistence logic rather 
than on data access plumbing. 
The Repository pattern is a well-documented way of working with a data source. In the book 
Patterns 
of Enterprise Application Architecture
, Martin Fowler describes a repository as follows: 
A repository performs the tasks of an intermediary between the domain model layers and data 
mapping, acting in a similar way to a set of domain objects in memory. Client objects declaratively 
build queries and send them to the repositories for answers. Conceptually, a repository encapsulates a 
set of objects stored in the database and operations that can be performed on them, providing a way 
that is closer to the persistence layer. Repositories, also, support the purpose of separating, clearly 
and in one direction, the dependency between the work domain and the data allocation or mapping. 
Define one repository per aggregate 
For each aggregate or aggregate root, you should create one repository class. You may be able to 
leverage C# Generics to reduce the total number concrete classes you need to maintain (as 
demonstrated later in this chapter). In a microservice based on Domain-Driven Design (DDD) patterns, 
the only channel you should use to update the database should be the repositories. This is because 
they have a one-to-
one relationship with the aggregate root, which controls the aggregate’s 
invariants and transactional consistency. It’s okay to 
query the database through other channels (as 
you can do following a CQRS approach), because queries don’t change the state of the database. 
However, the transactional area (that is, the updates) must always be controlled by the repositories 
and the aggregate roots. 
Basically, a repository allows you to populate data in memory that comes from the database in the 
form of the domain entities. Once the entities are in memory, they can be changed and then persisted 
back to the database through transactions. 
As 
noted earlier, if you’re using the CQS/CQRS architectural pattern, the initial queries are performed 
by side queries out of the domain model, performed by simple SQL statements using Dapper. This 
approach is much more flexible than repositories because you can query and join any tables you 
need, and these queries aren’t restricted by rules from the aggregates. That data goes to the 
presentation layer or client app. 
If the user makes changes, the data to be updated comes from the client app or presentation layer to 
the application layer (such as a Web API service). When you receive a command in a command 
handler, you use repositories to get the data you want to update from the database. You update it in 

---

241 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
memory with the data passed with the commands, and you then add or update the data (domain 
entities) in the database through a transaction. 
It’s important to emphasize again that you should only define one repository for each aggregate root, 
as shown in Figure 7-17. To achieve the goal of the aggregate root to maintain transactional 
consistency between all the objects within the aggregate, you should never create a repository for 
each table in the database. 
Figure 7-17. The relationship between repositories, aggregates, and database tables 
The above diagram shows the relationships between Domain and Infrastructure layers: Buyer 
Aggregate depends on the IBuyerRepository and Order Aggregate depends on the IOrderRepository 
interfaces, these interfaces are implemented in the Infrastructure layer by the corresponding 
repositories that depend on UnitOfWork, also implemented there, that accesses the tables in the Data 
tier.