Edition 0 Updated to asp. Net core 0

CQRS and DDD patterns are not top-level architectures 
It’s important to understand that CQRS and most DDD patterns (like DDD layers or a domain model 
with aggregates) are not architectural styles, but only architecture patterns. Microservices, SOA, and 
event-driven architecture (EDA) are examples of architectural styles. They describe a system of many 
components, such as many microservices. CQRS and DDD patterns describe something inside a single 
system or component; in this case, something inside a microservice. 
Different Bounded Contexts (BCs) will employ different patterns. They have different responsibilities, 
and that leads to different solutions. It is worth emphasizing that forcing the same pattern everywhere 
leads to failure. Do not use CQRS and DDD patterns everywhere. Many subsystems, BCs, or 
microservices are simpler and can be implemented more easily using simple CRUD services or using 
another approach. 

---

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