Venue: Internet
Guest Udi Dahan talks with host Robert Blumen about the CQRS (command query responsibility segregation) architectural pattern. The discussion begins with a review of the command pattern. Then a high-level overview of CQRS, which consists of a separation of a command processing subsystem that updates a write model from one or more distinct and separate, eventually consistent read models. Udi gives some insights into the relationship between CQRS and DDD (domain driven design) and the importance of involving a domain expert in the breakdown of a system into user-driven tasks, which become the basis for the commands. They then explore possibility of multiple read models, residing in different data stores, each one designed around the needs of different application views. They move into an exploration of the middleware technologies required to support the movement of updates between the write model and read models, including issues of concurrency, sequencing, and how much work can be done by the framework. Event sourcing, another pattern closely associated with CQRS is introduced, followed by a discussion about connections between event sourcing and CQRS. The host gets slightly confused on the boundaries between the two patterns, and Udi clarifies the distinction. They wrap up with some thoughts about why CQRS has received more attention in the Microsoft enterprise community than the Linux world, and Udi gives a detailed breakdown of where to learn about CQRS on the Web.
Show Notes
Related Links
- Udi Dahan’s blog: http://udidahan.com/
- Greg Young’s CQRS blog: http://goodenoughsoftware.net/2012/03/02/cqrs/
- CQRS case study on MSDN: http://msdn.microsoft.com/en-us/library/jj554200.aspx
- Domain Driven Design, the book, by Eric Evans: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215
- Implementing Domain Driven Design by Vaughan Vernon: http://www.amazon.com/Implementing-Domain-Driven-Design-Vaughn-Vernon/dp/0321834577/
- The EventStore open-source database: http://geteventstore.com/
- The Particular Service Platform for .NET: http://particular.net/
- CQRS mailing list: https://groups.google.com/forum/#!forum/dddcqrs
- Software Engineering Radio Episode 8: Eric Evans on Domain-Driven Design: https://www.se-radio.net/2006/03/episode-8-interview-eric-evans/
- Software Engineering Radio Episode 189: Eric Lubow on Polyglot Persistence: https://www.se-radio.net/2012/11/episode-189-eric-lubow-on-polyglot-persistence/
I think one of the key points that Udi makes a couple times, which is very important, is CQRS (and event sourcing, DDD, Messaging) are useful in relatively complex domains. Really CRUD’y domains, any of these concepts will cause more headaches and add unnecessary complexity.
Also, Udi also mentioned it, but when browsing blogs online and other readings, you may get the impression that CQRS requires you to have two models. It does not. The read and write models could be the same. In its simplest form, CQRS is just separating reads and writes into two classes.
Thank you for clarifying that CQRS is not suitable for CRUD style applications. I had the example of customer detail data (Stammdaten) in mind asked myself if CQRS would not amply the existing concurrency problems and, as Udi Dahan confirmed and explained, it does. I also found the idea of distinguishing between direct data manipulation and task-driven user interfaces helpful.
[…] SE Radio Episode 218: Udi Dahan on CQRS (Command Query Responsibility Segregation): http://www.se-radio.net/2015/01/episode-218-udi-dahan-on-cqrs-command-query-responsibility-segregati… […]
Thank you Udi.