The document discusses CQRS+ES (Command Query Responsibility Segregation and Event Sourcing), an architectural pattern that separates reading and writing data. CQRS divides an application into command and query components, where commands change state without returning data, and queries return data without changing state. Event sourcing records state changes as a sequence of events. The patterns improve scalability by allowing separate optimization of reads and writes. Benefits include reduced complexity, flexibility, testability, and easy integration with external systems through use of events and separation of read and write models and data stores. The document provides an overview of CQRS+ES and its benefits for addressing issues like large read/write imbalances, complex domain logic,

1. Título Apresentação
Nome Rubrica
Título
do Slide
CQRS+ES
What? Why? How?
DevDays | 2014

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

6. Título Apresentação
Nome Rubrica
Título
do Slide
CQRS+ES: What? Why? How?
DevDays
2014