Command–query separation

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search

Command–query separation (CQS) is a principle of imperative computer programming. It was devised by Bertrand Meyer as part of his pioneering work on the Eiffel programming language.

It states that 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.[1] More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.

Connection with design by contract[edit]

Command–query separation is particularly well suited to a design by contract (DbC) methodology, in which the design of a program is expressed as assertions embedded in the source code, describing the state of the program at certain critical times. In DbC, assertions are considered design annotations – not program logic – and as such, their execution should not affect the program state. CQS is beneficial to DbC because any value-returning method (any query) can be called by any assertion without fear of modifying program state.

In theoretical terms, this establishes a measure of sanity, whereby one can reason about a program's state without simultaneously modifying that state. In practical terms, CQS allows all assertion checks to be bypassed in a working system to improve its performance without inadvertently modifying its behaviour. CQS may also prevent the occurrence of certain kinds of heisenbugs.

Broader impact on software engineering[edit]

Even beyond the connection with design by contract, CQS is considered by its adherents to have a simplifying effect on a program, making its states (via queries) and state changes (via commands) more comprehensible.[citation needed]

CQS is well-suited to the object-oriented methodology, but can also be applied outside of object-oriented programming. Since the separation of side effects and return values is not inherently object-oriented, CQS can be profitably applied to any programming paradigm that requires reasoning about side effects.[citation needed]

Other architectural patterns[edit]

  • As we move away from a single representation that we interact with via CRUD, we can easily move to a task-based UI.
  • CQRS fits well with event-based programming models. It's common to see a CQRS system split into separate services communicating with Event Collaboration. This allows these services to easily take advantage of Event Sourcing.
  • Having separate models raises questions about how hard is to keep those models consistent, which raises the likelihood of using eventual consistency.
  • For many domains, much of the logic required is needed when you're updating, so it may make sense to use Eager Read Derivation to simplify your query-side models.
  • If the write model generates events for all updates, you can structure read models as Event Posters, allowing them to be Memory Images and thus avoiding a lot of database interactions.
  • CQRS is suited to complex domains, the kind that also benefits from Domain-Driven Design. [2]

Command query responsibility segregation[edit]

Command query responsibility segregation (CQRS) applies the CQS principle by using separate Query and Command objects to retrieve and modify data, respectively.[3][4]

See also[edit]


  1. ^ Meyer, Bertrand. "Eiffel: a language for software engineering" (PDF). p. 22. Retrieved 16 December 2014.
  2. ^ "What is CQRS". What is CQRS. Retrieved 2019-06-27.
  3. ^ Young, Greg. "CQRS Documents" (PDF). Retrieved 2012-12-28.
  4. ^ Fowler, Martin. "CQRS". Retrieved 2011-07-14.

Further reading[edit]

External links[edit]