CQRS stands for "Command Query Responsibility Segregation". The idea is an extension of the single responsibility principle applied to services:
Command and Query are responsibilities of a system. By single responsibility principle, each of these responsibilities should be separate in the system.
"How tho?" As with all design principles: giving the definition does not teach how to apply the principle. :)
There are a lot of technologies that enable CQRS and these are worth an overview. I want to focus on the conceptual and logical first. The critical aspect of segregating command and query is useful even in design.
For instance, a useful question: "Does this change the state of the system?". This likely resembles asking about purity to functional programmers. Yep, same idea :) Just applied early and often in the design. We should aim for a clear answer: Yes or no. If there isn't a clear answer then that likely indicates a poor separation of command and query.
Is this an interesting topic for anybody else?
Top comments (2)
I find CQRS pretty interesting. I wrote an article last year about some of our practices.
For me, CQRS answered a problem that I kept running into when I would create applications. Using 3 layer program structure, I always ended up with a bloated data model that shared concerns of both the presentation and business layers. It became harder to maintain over time as it became less clear which bits of data were important (read as: changes were breaking) to which layer. Because they were all housed in the same set of normalized tables. Even applying CQRS at a minimal level (for example, separate tables for business logic vs presentation, writing to both on save) helps to improve the situation.
The problem with learning about this practice is that it has been conglomerated with a lot of other things over time. So when you try to learn about it, you end up "drinking from the firehose" of myriad other dimensions around it (like DDD, event sourcing, eventual consistency, optimistic concurrency, etc). I also utilize most of these since they are progressive optimizations, but the pattern is usable without them. And the shift in thinking was too big for me to do all at once.
Great article! Thanks for sharing :)