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.
Dostları ilə paylaş: