Edition 0 Updated to asp. Net core 0

Additional resources 
•
Greg Young. Versioning in an Event Sourced System
(Free to read online e-book) 
https://leanpub.com/esversioning/read
 
Apply CQRS and CQS approaches in a DDD 
microservice in eShopOnContainers 
The design of the ordering microservice at the eShopOnContainers reference application is based on 
CQRS principles. However, it uses the simplest approach, which is just separating the queries from the 
commands and using the same database for both actions. 
The essence of those patterns, and the important point here, is that queries are idempotent: no matter 
how many times you quer
y a system, the state of that system won’t change. In other words, queries 
are side-effect free. 

---

187 
CHAPTER 6 | Tackle Business Complexity in a Microservice with DDD and CQRS Patterns 
Therefore, you could use a different “reads” data model than the transactional logic “writes” domain 
model, even though the ordering microservices are using the same database. Hence, this is a 
simplified CQRS approach. 
On the other hand, commands, which trigger transactions and data updates, change state in the 
system. With commands, you need to be careful when dealing with complexity and ever-changing 
business rules. This is where you want to apply DDD techniques to have a better modeled system. 
The DDD patterns presented in this guide should not be applied universally. They introduce 
constraints on your design. Those constraints provide benefits such as higher quality over time, 
especially in commands and other code that modifies system state. However, those constraints add 
complexity with fewer benefits for reading and querying data. 
One such pattern is the Aggregate pattern, which we examine more in later sections. Briefly, in the 
Aggregate pattern, you treat many domain objects as a single unit as a result of their relationship in 
the domain. You might not always gain advantages from this pattern in queries; it can increase the 
complexity of query logic. For read-only queries, you do not get the advantages of treating multiple 
objects as a single Aggregate. You only get the complexity. 
As shown in Figure 7-2 in the previous section, this guide suggests using DDD patterns only in the 
transactional/updates area of your microservice (that is, as triggered by commands). Queries can 
follow a simpler approach and should be separated from commands, following a CQRS approach. 
For implementing the “queries side”, you can choose between many approaches, from your full
-blown 
ORM like EF Core, AutoMapper projections, stored procedures, views, materialized views or a micro 
ORM. 
In this guide and in eShopOnContainers (specifically the ordering microservice) we chose to 
implement straight queries using a micro ORM like 
Dapper
. This guide lets you implement any query 
based on SQL statements to get the best performance, thanks to a light framework with little 
overhead. 
When you use this approach, any updates to your model that impact how entities are persisted to a 
SQL database also need separate updates to SQL queries used by Dapper or any other separate (non-
EF) approaches to querying.