Quick understanding of CQRS
CQRS means that the responsibility for commands and queries is separate. Many people mistakenly think that CQRS is an overall architecture. In fact, CQRS is a small model, which was first proposed by Greg Young and Udi Dahan. They were inspired by the separation of commands and queries from Bertrand Meyer's "Object Oriented Software Construction". The main idea behind CQS is: "A method should change the state of an object, or return a result, but not both. In other words, asking a question should not change the answer to the question. More formally, a method will only return a value if it is referenced referentially transparent and has no side effects."
Because of this, we divide the methods into two categories:
Commands-change the state of an object or the entire system
Queries-returns the result without changing the state of the object
In reality, it is easy to say what is what. Queries declares the return type, and commands does not return a value. This pattern is universal, and it makes the object simpler. In other words, CQRS can only be used to solve specific problems.
Many applications use mainstream methods of reading and writing to build objects. Using read and write for the same model (model) makes model more complex, and it is very difficult to maintain and optimize.
The real strategy of these two modes is that you can separate the modified state from the unmodified state, which can make it difficult to deal with performance and tuning. You can optimize the parts of the system that are used separately for reading in the write part, which is a known domain, which contains all the behavior, and the read part is designated to provide services for the report.
Another benefit of this model in a large application is that you can assign developers to smaller teams to perform different tasks of the system (only read or write), regardless of other tasks. For example, developers of the reading section do not need to understand the domain model.
View the original text: Kanasz Robert
