188
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
There is only one application architecture: the architecture of the system or end-to-end application
you are designing (for example, the microservices architecture). However, the design of each Bounded
Context or microservice within that application reflects its own tradeoffs and internal design decisions
at an architecture patterns level. Do not try to apply the same architectural patterns as CQRS or DDD
everywhere.
Additional resources
•
Martin Fowler. CQRS
https://martinfowler.com/bliki/CQRS.html
•
Greg Young. CQRS Documents
https://cqrs.files.wordpress.com/2010/11/cqrs_documents.pdf
•
Udi Dahan. Clarified CQRS
https://udidahan.com/2009/12/09/clarified-cqrs/
Implement reads/queries in a CQRS microservice
For reads/queries, the ordering microservice from the eShopOnContainers
reference application
implements the queries independently from the DDD model and transactional area. This
implementation was done primarily because the demands for queries and for transactions are
drastically different. Writes execute transactions that must be compliant with the domain logic.
Queries, on the other hand, are idempotent and can be segregated from the domain rules.
The approach is simple, as shown in Figure 7-3. The API interface is implemented by the Web API
controllers
using any infrastructure, such as a micro Object Relational Mapper (ORM) like Dapper, and
returning dynamic ViewModels depending on the needs of the UI applications.
Figure 7-3. The simplest approach for queries in a CQRS microservice
The simplest approach for the queries-side in a simplified CQRS approach can be implemented by
querying the database with a Micro-ORM like Dapper, returning dynamic ViewModels.
The query
189
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns
definitions query the database and return a dynamic ViewModel built on the fly for each query. Since
the queries are idempotent, they won’t change the data no matter how many times you run a query.
Therefore, you don’t need to be re
stricted by any DDD pattern used in the transactional side, like
aggregates
and other patterns, and that is why queries are separated from the transactional area. You
query the database for the data that the UI needs and return a dynamic ViewModel that does not
need to be statically defined anywhere (no classes for the ViewModels) except in the SQL statements
themselves.
Since this approach is simple, the code required for the queries side (such as code using a micro ORM
like
Dapper
)
can be implemented
within the same Web API project
. Figure 7-4 shows this approach.
The queries are defined in the
Dostları ilə paylaş: