CQRS is Software Development Schizophrenia

Thomas Hansen - Jul 8 '22 - - Dev Community

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 ... :/

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .