Software Engineering Radio - the podcast for professional software developers Episode 218: Udi Dahan on CQRS (Command Query Responsibility Segregation)
4 snips
Jan 30, 2015 
In this engaging discussion, Udi Dahan, a pioneer in service-oriented architecture and co-originator of the CQRS pattern, dives into the nuances of Command Query Responsibility Segregation. He explains how separating read and write models can simplify complex domains, and outlines the benefits of event sourcing for preserving object state. Udi also touches on vital infrastructure choices and emphasizes the importance of collaborating with domain experts to select the right architectural patterns for specific needs.
AI Snips
Chapters
Books
Transcript
Episode notes
Commands Need Freshness, Queries Can Be Stale
- Queries and commands have different correctness and staleness needs, so they pull models in different directions.
- CQRS applies single-responsibility by splitting command logic (strong consistency) from query logic (tolerant of staleness).
Design Persistence To Match Responsibilities
- Evaluate separate persistent models for queries and commands only when complexity justifies it.
- Design query data structures explicitly if you want clean, highly optimized command and query layers.
Pick Storage By Access Pattern
- Different data stores suit different domain needs: relational normalization for writes, denormalized or other stores for reads and graph or document stores when optimal.
- CQRS often pairs well with NoSQL where persistence shape matches access patterns.
