[This is the first episode in my CQRS Overview Series - Series Contents]
Is it worth my time even thinking about CQRS, much less dedicating precious time and energy to understanding it? In this post, I hope to demonstrate two things: first that CQRS consists of simple concepts, and second, that it is certainly worth your time to understand these basic concepts. You may still choose to only adopt certain approaches and techniques made possible by CQRS. However, by understanding CQRS you will discover new ways of thinking about requirements gathering, design, architecture and implementation. These thinking processes provide benefits even if you don't implement every possible recommendation or option you read about here or in other sources of information about CQRS.
CQRS (Command Query Responsibility Segregation) grew out of a concept called CQS (Command Query Separation). Bertrand Meyer coined the term CQS which is defined this way: "every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer" (Wikipedia/Command-query separation).
CQS provides a basic separation of concerns in which any method will either modify state, or return data. Methods following the CQS principle communicate context through the asking one simple question - is this method a Command or a Query? Methods which try to fulfill both roles are often brittle, long, complex, difficult to change, or hard to test (or a combination of many of these factors). By separating our commands and queries, we take a large step toward preventing these problems from entering our code base.
Stop for a moment to ponder the simplicity of CQS. All we are doing is thinking about whether a method is going to do something, or return some data. You can hardly get much more dirt simple than that. This is a fundamental and simple principle, but with profound implications. This becomes especially true when we extend the CQS concept beyond the method level and apply it generally to the design of the whole system.
CQRS makes this leap from a method level to a system level. A distinction is made between Commands which tell the system to take an action, and Queries which ask the system for information. This approach helps at the conceptual level when thinking about the design of a system. By separating these concerns, your mental process can take on a more fine grained approach to designing the system. It helps you to begin speaking the language of the business. Commands represent actions taken in actual business processes. Queries represent data as it is presented in actual business scenarios. Developers start thinking about the application in business terms, rather than expecting business people to adopt the technical language of developers.
In summary, CQRS comes down to a simple concept, but with extensive implications. In the next article in this series, I'll dive more deeply into the specifics of how Commands bring power, elegance and simplicity to the design and development process. Stay tuned.
Tags: CQRS, DDD, Domain Driven Design