Edition 0 Updated to asp. Net core 0

public
class
BuyerRepository : IBuyerRepository 
{ 
private
readonly
OrderingContext _context; 
public
IUnitOfWork UnitOfWork 
{ 
get 
{ 
return
_context; 
} 
} 
public
BuyerRepository
(OrderingContext context) 
{ 
_context = context ?? 
throw
new
ArgumentNullException
(
nameof
(context)); 
} 
public
Buyer 
Add
(Buyer buyer) 
{ 
return
_context.
Buyers
.
Add
(buyer).
Entity
; 
} 
public
async Task 
FindAsync
(
string
buyerIdentityGuid) 
{ 
var
buyer = await _context.
Buyers
.
Include
(b => b.
Payments
) 
.
Where
(b => b.
FullName
== buyerIdentityGuid) 
.
SingleOrDefaultAsync
(); 
return
buyer; 
} 
} 
} 

---

248 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
The 
IBuyerRepository
interface comes from the domain model layer as a contract. However, the 
repository implementation is done at the persistence and infrastructure layer. 
The EF DbContext comes through the constructor through Dependency Injection. It is shared between 
multiple repositories within the same HTTP request scope, thanks to its default lifetime 
(
ServiceLifetime.Scoped
) in the IoC container (which can also be explicitly set with 
services.AddDbContext<>
). 
Methods to implement in a repository (updates or transactions versus queries) 
Within each repository class, you should put the persistence methods that update the state of entities 
contained by its related aggregate. Remember there is one-to-one relationship between an aggregate 
and its related repository. Consider that an aggregate root entity object might have embedded child 
entities within its EF graph. For example, a buyer might have multiple payment methods as related 
child entities. 
Since the approach for the ordering microservice in eShopOnContainers is also based on CQS/CQRS, 
most of the queries are not implemented in custom repositories. Developers have the freedom to 
create the queries and joins they need for the presentation layer without the restrictions imposed by 
aggregates, custom repositories per aggregate, and DDD in general. Most of the custom repositories 
suggested by this guide have several update or transactional methods but just the query methods 
needed to get data to be updated. For example, the BuyerRepository repository implements a 
FindAsync method, because the application needs to know whether a particular buyer exists before 
creating a new buyer related to the order. 
However, the real query methods to get data to send to the presentation layer or client apps are 
implemented, as mentioned, in the CQRS queries based on flexible queries using Dapper.