What is CQRS ?
CQRS stands for Command Query Responsibility Segregation. It’s a pattern which will let you handle complex applications with a structure different than CRUD. You may hear the term CRUD stands for create, read, update and delete, which is the normal mental method of plenty of programmers today. But with CQRS you can handle problems differently.
In this article I want to talk about how CQRS is structured and what are the advantages and disadvantages of that. But before that, I should say you must be cautious about the added complexity of CQRS to your system because of its nature. You should be only use CQRS where it is suitable and will match with your needs, because if you use it when it should not be, you may face additional and unnecessary complexity in your system and your productivity will be slow down. So with that in mind, lets deep dive into CQRS.
Structure of CQRS
In CQRS we will basically differ query model of our system from the command model. It means we treat differently when we want to query our database than when we want to update our database.
In the above figure you can see there is two separated models. One for Command and another for Query. In a complex system where there is lots of transactions and logic of the system is complex and data input to system is huge, this will greatly help us to improve the performance and avoid boilerplate code. In comparison with CRUD model we have added more complexity because we split read section from other sections, but in some situations separating read section will gain us a huge performance improvement and also we can reason about data better. We will talk about this later in this article that how we can integrate CQRS with event-sourcing to achieve that.
Advantages of CQRS
In large and complex systems, we often face performance looses and raised complexity and boilerplate code. Using CQRS we can eliminate these problems from scratch and bring a good performance for our users and narrow down lots of boilerplate codes.
Also separating query section from command section will let us freedom in these different parts. For example we can implement our reading part totally differently from our command part to use special resources for fast data reads. But those resources are not required in command part, therefore they will not add there.
Another advantage of using CQRS in right place is scalability. For example we can scale query part without worry of breaking the command part, because they are totally separated from each other.
Disadvantages of CQRS
One of the main disadvantages of CQRS is its complex structure in early state of creating system. Because it has some fundamentals that are hard to implement, it may have complexity to start with.
Another disadvantage of CQRS is that when we separate query model from command model, we should implement them also if they may be implement in the same manner. So it will take some more code. But actually this will fall back on invalid use of CQRS. Because CQRS is for where command section is different from query section.
Integration with Event-sourcing
Using CQRS in integration of event-sourcing will let us to not modify data directly and announce any changes in data only using events. So we can actually keep a history of all events in our system in a timeline based manner.
In this strategy we have certainly different query and command sections and we can benefit from performance improvements of query model as well as benefits of event-sourcing to keep track of data changes and navigate through the time.
Is There any Framework for CQRS?
The good news is Yes! There is some framework for CQRS and most of them also use event-sourcing. For example you can take a look at Lagom which is free and supports Java and Scala.
Conclusion
When using CQRS in the right situation, it will give you numerous possibilities like scaling your system quickly and implement your changes flexibly. This will save us lots amount of time and you know time is money, so it will bring us very good values.
But always keep in mind to use CQRS in the right situation to avoid unnecessary added complexity.
When integrating with event-sourcing, this will even let us more power and let us to keep a history of all changes in our system. This will be very useful for systems like accounting where the history is quite important.
