This document discusses Command Query Responsibility Segregation (CQRS). It begins with an agenda and overview of why CQRS is used, including for complex domains, separating read and write boundaries, and enabling scalability. It then explains the typical architecture with one object for data access versus CQRS, which separates reads and writes into different objects or services. The document outlines some of the benefits of CQRS like skill set segregation and enabling divergent models. It also notes that CQRS is not a top-level architecture, but can be applied within bounded contexts, and emphasizes that CQRS is simply separating reads from writes rather than implying specific patterns or technologies.
7. Typical Architecture - Analysis
•
•
•
•
•
Simple & Common
Tooling: ActiveRecord, ORM, AutoMapper.
Data Driven
Potentially Anemic Domain Model
Hard to scale data storage
8. Command Query Separation
Every method should either be a command
that performs an action, or a query that
returns data to the caller, but not both.
9. Command Query Responsibility Segregation
”CQRS is simply the creation of two objects
where there was previously only one.”
-Greg Young
12. "Defining the CQRS pattern is easy. Realizing the
benefits that implementing the CQRS pattern can
offer is not always so straightforward."
– Microsoft Patterns & Practices
"This simple notion leads to some profound
consequences for the design of information
systems."
–Martin Fowler
24. Takeaways
•
•
•
Separate reads and writes between two
objects.
That’s it.
Everything else (DDD, Event Sourcing,
Messaging…) is not CQRS. They just fit
extremely well.