CQRS is an acronym, and it implies "Command Query Responsibility Segregation" - Which again just translates to that you've got a different strategy for storing and retrieving data.
During my 25 years as a professional software developer, and 40 years in total, I think I have seen one app that required CQRS, but I've seen hundreds of apps implementing CQRS. This disparity between actual usage and need is really just a symptom of CV based software development, where the developer having implemented the original design cares more about building his CV than solving the needs of his employer.
To understand why this is insanity, realise that typically the complexity of your problem easily increases 10 folds if you add CQRS to your app. With CQRS you typically need a message broker, where none was needed originally. Installing Pulsar, Kafka, or RabbitMQ can easily cost you a month of development, simply to get its configuration files applied correctly. Afterwards you'll typically have to start thinking about micro service transactional objects, Sagas, record locking, etc, etc, etc. You've effectively magnified the scope of the problem 1 million times.
Even Martin Fowler suggests to avoid CQRS when you can, and use CRUD instead. FYI, when Martin advices against something because of added complexity, you can be pretty sure about that it freakin' adds a lot of complexity ... ;)
At Aista we have taken a more bold approach. Yes, we do have web sockets and even implemented these as a simple checkbox you can use when generating your CRUD backends, resulting in web socket messages asynchronously published during write invocations, which arguably could be defined as a CQRS strategy. However, fundamentally, we will do everything we can to avoid adding complexity to your projects if we can.
Whenever somebody on your team suggests CQRS you need to be very careful, and your knee jerk reaction should be believing in that the person is more interested in adding complexity for fun, and to add "new shiny things" to his CV, than he (or she) is about solving your company's problem.
99.9999999999999% of apps in this world do not need CQRS! Implying 99.999% of all apps that has CQRS are basically "junkware", implemented that way by selfish software developers, for their own selfish needs, and the best thing to do really is to simply do SHIFT+DELETE refactoring of the whole thing ... :/
In the video below I am creating a CRUD Web API in 1 second. If you ask a medium sized software development team to implement the same using CQRS, they could easily spend years, and there would be a 90% statistical probability of that they would never succeed. Even if they succeeded, the complexity of the thing would render it impossible to maintain, and also highly likely scattered with security issues, and the thing would end up becoming "junkware" in the end.
Don't use CQRS, use CRUD please ... :/
Top comments (7)
I'm an engineering manager at a rather large e-commerce company in Germany, and I've never worked with, or implemented any systems using CQRS, though I'm sure our organization has quite a few services using it. I agree with the statements in this article to a large extent, however I think it is ignoring a lot of the problems CQRS is meant to solve, which is primarily not something CRUD can do for you out of the box.
To be a little more specific, CQRS usually comes up with event sourcing, where you not only want to know the current state, but also to be able to track down changes. Now I'm not saying that CQRS is the only way doing it, but ignoring it completely leaves your post a bit unfinished in my opinion.
You should probably also extend the post on how the benefits of CQRS itself, namely the separation of reads and writes, and hence making scalability easier, can be compensated for by CRUD combined with other techniques.
Notice how I liked your comment? 😉
You are right. My target isn’t to remove CQRS from apps that needs it, my target is to remove it from apps that doesn’t need it. If you’re for instance building a real time trading platform with hundreds of writes per second, you obviously have to use CQRS. However, using it when it’s not needed is madness, and I’ve seen it used a LOT when it wasn’t needed.
I guess that's fair, though you could have gone slightly further by adding a checklist about when it's actually a good idea to go with CQRS. ;)
That might be, but it would probably be difficult to ensure it was complete. Great developers knows when to apply it intuitively, which of course is (almost) never 😊
I like the "cooler heads prevail" approach. Seems like it's a lost quality in today's engineers.
Send him my article 😉
Or, better, send it to your CEO 😉
I found cqrs very practical so I can test my ui stateless. You can also do it without using a broker at all. Just plain old objects and callbacks. Observables make the api neat and readable, but that's it.
My testing was simply 'when state contains this, button is visible'
'on click of button event got dispatched "
'on Event, state got modified (or sent http request to server and stored response) '
Sure, it's 3 unit tests, but it really helps.
Bases on your posts I belive you've used angular, so a good companion was 'ngxs'