185
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
CQS is a simple concept: it is about methods within the same object being either queries or
commands. Each method either returns state or mutates state, but not both.
Even a single repository
pattern object can comply with CQS. CQS can be considered a foundational principle for CQRS.
Command and Query Responsibility Segregation (CQRS)
was introduced by Greg Young and strongly
promoted by Udi Dahan and others. It is based on the CQS principle, although it is more detailed. It
can be considered a pattern based on commands and events plus optionally on asynchronous
messages. In many cases, CQRS is related to more advanced scenarios, like having a
different physical
database for reads (queries) than for writes (updates). Moreover, a more evolved CQRS system might
implement
Event-Sourcing (ES)
for your updates database, so you would only store events in the
domain model instead of storing the current-state data. However, this approach is not used in this
guide. This guide uses
the simplest CQRS approach, which consists of just separating the queries from
the commands.
The separation aspect of CQRS is achieved by grouping query operations in one layer and commands
in another layer. Each layer has its own data model (note that we say model, not necessarily a different
database) and is built using its own combination of patterns and technologies.
More importantly, the
two layers can be within the same tier or microservice, as in the example (ordering microservice) used
for this guide. Or they could be implemented on different microservices or processes so they can be
optimized and scaled out separately without affecting one another.
CQRS means having two objects for a read/write operation where in other contexts there is one. There
are reasons to have a denormalized reads database, which you can learn
about in more advanced
CQRS literature. But we are not using that approach here, where the goal is to have more flexibility in
the queries instead of limiting the queries with constraints from DDD patterns like aggregates.
An example of this kind of service is the ordering microservice from the eShopOnContainers reference
application. This service implements a microservice based on a simplified CQRS approach. It uses a
single data source or database, but two logical models plus DDD patterns
for the transactional
domain, as shown in Figure 7-2.
186
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
Figure 7-2. Simplified CQRS- and DDD-based microservice
The Logical “Ordering” Microservice includes its Ordering database, which can be, but doesn’t
have to
be, the same Docker host. Having the database in the same Docker host is good for development, but
not for production.
The application layer can be the Web API itself. The important design aspect here is that the
microservice has split the queries and ViewModels (data models especially created for the client
applications)
from the commands, domain model, and transactions following the CQRS pattern. This
approach keeps the queries independent from restrictions and constraints coming from DDD patterns
that only make sense for transactions and updates, as explained in later sections.
Dostları ilə paylaş: