2. Título Apresentação
Nome Rubrica
Título
do Slide
CQRS+ES
DevDays 2014
What is it?
“CQRS is simply the creation of two objects where there was previously only one”
Command Query Responsibility Segregation (CQRS) is an architectural pattern,
based on the concept that methods should be either commands or queries, and
separates responsibility handling at the component level:
A command changes the state, does not return data
A query returns data, does not alter the state
Event Sourcing (ES) is also an architectural pattern, that ensures the capture of
application state changes as a sequence of events.
Combining of these two patterns ensures consistency between reads and writes.
3. Título Apresentação
Nome Rubrica
Título
do Slide
CQRS+ES
DevDays 2014
Why use it?
“A single model cannot be appropriate for reporting,
searching and transactional behavior”
too many layers
big data models (try to capture all)
anemic domain model (lack of behavior)
focus on frameworks, not on the domain
scalability not considered in core design
integration is often an after thought
different clients require different
perspectives on data
Solution and Code Complexity
large imbalance between the number of
reads and writes
domain involves complex business logic
a single model encapsulating
reads/writes does neither well
can also occur at the data store level
separate optimization of reads and writes
security can be very fine grained
Reasons for Segregation
4. Título Apresentação
Nome Rubrica
Título
do Slide
CQRS+ES
DevDays 2014
Why use it?
“State transitions are an important part of our problem space
and should be modeled within our domain”
focus on business
manage business and technology risks
separately
queries do not use business model
no object-relational impedance mismatch
scalable, flexible and testable
reduced complexity and simplified
system architecture
Common Benefits
explicit error/failure modeling
easy integration with external systems
location transparency
reactive behavior
bullet-proof auditing and historical tracing
Event Sourcing Benefits
5. Título Apresentação
Nome Rubrica
Título
do Slide
CQRS+ES
DevDays 2014
How to?
event bus
command bus
command
handlers
query
handlers
write
store
Command Services
Query Services
event
handlers
read
store
domain repositories
commands
query results
event bus
query facade
Commands, Queries and Events provide for natural integration interfaces
CQRS applies the CQS principle by using separate Query and Command objects to retrieve and modify data respectively:
Commands request the system to perform a task or action
Queries request a particular data view or system report
It was first documented by Greg Young & Udi Dahan
CQRS is not a top level architecture.
Scaling benefits:
host read/write services differently
Read side benefits:
top-down driven and optimized view data model
denormalized schema (no joins)
no mapping or ORM mismateches
easy queries
Write side benefits:
behavioral driven
exposes only functionality
event driven (state machine)
forms a consistency boundary
Control and Data Flow:
write side receive Commands and publish Events
all state changes are represented by Business Events
read side is updated as a result of the published Events
all Queries go directly to the Reporting, the Business-logic is not involved
Event Sourcing Flow:
every state change is materialized in an Event
all Events are sent to an event processor
event processor stores all events in a event store
system can be reset and event store replayed
many different event listeners can be added
no need for ORM, just persist the Events