To understand CRQS better, let’s take a glance at CQS (Command Query Segregation). This type of modeling is really productive around the system, where the command and query can be modeled separately. Command Query Response Segregation is an extension of CQS in which command query and response are modeled separately.
The model is followed in the domain-driven design. The purpose of separating this model is to increase scalability, flexibility, performance security, and the domain encapsulation.
The image, given below, is a high level explanation of the model:
![high level]()
The important thing to be considered here is the separation of the models at the multiple stages. The command can be any type of command from the domain. Let’s say, we discuss banking sector, the command can be to create an account of updated account information. Let's say we have a command update account, the domain will handle it, do some actions and after those actions, the domain will launch the events. Events are something that have already happened. In this case, the event account updated will launch. Based on this event, we can have handlers, which can perform the actions on our read models.
A more detailed model is given below:
![model]()
In this model, the view is usually the UX. The best practice is to have one UI for a resulting UI. Thus, if I have a page where I am showing all the ‘accounts payable’, it means I should have a table (read model) in the DB having the information about the accounts payable. Now, why we do it is the question to be asked. If the information is already available, why we don’t use joins to collect that information? The reason behind that is off course scalability, flexibility and the performance. If for some reason, I want to change my base tables, it won’t affect my view or the read model. They are always flexible and extendable. Thus, if I want to add or remove the information, that's really easy to do. Lastly is the advantage of the performance, having an exact information available will make the view more ‘snappy’.
The command is sent from the view to the domain, where the domain logic is applied. Now, these commands can be updates, added, removed or modified. These commands are something that the system is supposed to do so. The command can be ‘Add_User’ or ‘Delete_user’. When the domain logic is applied to it, the domain will react and will launch the events. The events are some action that has already happened. Hence, in our case, it will be ‘User_Added’ or ‘User_Deleted’. We can have many listeners on these events like some listeners are responsible for updating the read models accordingly, while some listeners are responsible for performing more domain logic, based on these events. Thus, here, we can create a system behavior, using the events chain. Certain event sourcing techniques and write models are used here in more complex systems but we won’t do in detail.
In my next article, I will write more details about the internals of the event sourcing, aggregation and the read-write models.