4. Query
Returns data
Doesn’t alter
state
Command
Alter state
Doesn’t
return data
Separation
Responsibility
Bertrand Meyer called it
Command/Query Separation back in the 1980s
5. ONE BIG ISSUE LEADING TO CQRS
How to design a single model to address of all
aspects and concerns of a business domain?
How to do that effectively?
Theory
Begin End
Practice
9. O(C x Q) vs. O(C + Q)
ONE BIG ISSUE LEADING TO CQRS
We faced a lot of complexity in modeling and
we thought it was inherent domain complexity
10. Benefits Simplification
of the design
Potential for
enhanced
scalability
Side effects
Easier to
maintain and
evolve stacks
Optimize each
stack
separately
ASPECTS OF CQRS
12. FLAVORS OF CQRS
• TX Script
• Your choice of DAL
• Shared DB
Regular
• Aggregates
• Your choice of DAL
• Data DB + snapshots
Premium
• Event-driven architecture
• LET or any choice of DAL
• Data DB + snapshots + event store
Deluxe
13. REGULAR CQRS
PRESENTATION
TX SCRIPT TX SCRIPT
APPLICATION APPLICATION
DAL
Simply use s-procs to
read or ADO.NET or EF
or whatever else suits
you. Just use DTO to
bring data back.
14. PREMIUM CQRS
PRESENTATION
DOMAIN LAYER
APPLICATION APPLICATION
DAL
Business logic
implemented through
aggregates and
domain model. State
of aggregates also
persisted in a format
suitable for the UI.
Sync
16. DELUXE CQRS
APPLICATION
Application logic
expressed through
commands pushed to
a bus generating
events handled by
sagas (stateful) and
handlers (stateless).
Optionally events
recorded to a log.
Sync
DOMAIN LAYER Event
store
QUERY
STACK
…
Saga(s) Handler(s)
BUS
17. AT THE VERY END OF THE DAY
CQRS brings just one core idea: keep write and read
stacks completely separated and based on different
models and even different implementation patterns and
technologies.
Best-selling point of CQRS is that it looks like common
sense and a smarter way of doing just the same things.
CQRS is not a philosophy or a methodology:
it's just about writing code.