Member-only story
SOFTWARE ARCHITECTURE & REFACTORING
3 CQRS Architectures that Every Software Architect Should Know
Separation of concerns is a technique for the effective ordering of one’s thoughts. You should focus one’s attention upon one aspect. — Edsger W. Dijkstra
Command-Query Separation (CQS)
In 1988 Bertrand Meyer devised the CQS principle for object-oriented languages in the book Object-Oriented Software Construction. In simple words, the principle says that software should either modify the system (commands) or return values (queries) and you should maintain the command-query separation in your software.
Martin Fowler in his blog post from 2005 is saying that it is not always possible to achieve such separation and he is right. A good example of it is returning the id of the just inserted record. First, you are saving the records into persistence (command) and second, you are getting its newly assigned id (query).
CQRS Architectures
Command Query Responsibility Segregation (CQRS) architectures expand the concept of command-query division at the architectural level. But these architectures are not architectures of the whole software system. It is a design of just one part of the software and that part is called the Application Layer.
If you are looking for the architectures of the entire software system, follow the link to my article about Domain-Centric Architectures below.
CQRS suggests dividing the Application Layer into two sides, the commands side, and the queries side.
The queries side should be responsible and optimized for reading data. Queries are reading data from persistence and then map them into the presentation layer required form. Such forms are mostly identified as Data Transfer Objects (DTOs).
