Command–query separation

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

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

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.

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.

Command query responsibility segregation

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

Other architectural patterns
  • 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 Driven Architecture.
  • 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. [4]

See also

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

Further reading
  • Meyer, Bertrand (September 1994) [1988]. Object-oriented Software Construction. Prentice Hall. ISBN 0-13-629049-3.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.