{"id":1535,"date":"2019-09-19T00:00:00","date_gmt":"2019-09-18T22:00:00","guid":{"rendered":"https:\/\/demo.sidekick.be\/itenium\/cqrs-ramble\/"},"modified":"2025-11-28T13:31:44","modified_gmt":"2025-11-28T12:31:44","slug":"cqrs-ramble","status":"publish","type":"post","link":"https:\/\/demo.sidekick.be\/itenium\/blog\/design\/cqrs-ramble\/","title":{"rendered":"CQRS and CRUD"},"content":{"rendered":"

I\u2019ve always loved CQS<\/a>. How could one not, it makes perfect sense that getUser(5)<\/code> would return user \u201c5\u201d and not do much else, perhaps there is some caching in place but one would hope it doesn\u2019t actually create a User record or something.<\/p>\n

Then Greg Young introduced CQRS: An architectural pattern that allows us to add nice things, like Event Sourcing or a reporting database pretty easily. Adding such significant changes might be much easier compared to the impact on a more classical architecture, even when doing so late in the development life cycle.<\/p>\n

\n

Despite these benefits, you should be very cautious about using CQRS<\/strong>
\u2014 Martin Fowler<\/em><\/p>\n<\/blockquote>\n

In his entire article on CQRS, this is the only sentence that Martin has put in bold.<\/p>\n

Unfortunately developers like the latest and greatest very much and CQRS has, for many organizations and teams been put forward as the de facto standard architecture.<\/p>\n

There is of course that one project where it makes a lot of sense but let\u2019s be realistic, most of us are working on enterprise applications which are all pretty much CRUD.<\/p>\n

So let\u2019s explore what usually happens when you use CQRS for a CRUD application\u2026<\/p>\n

The CQRS Mayhem<\/h1>\n

An often overlooked aspect of design patterns are the Consequences<\/code>:<\/p>\n

\n

How does the pattern support its objectives? What are the trade-offs and results of using the pattern? What aspect of the system structure does it let you vary independently?
\u2014 Design Patterns: Elements of Reusable Object-Oriented Software<\/em><\/p>\n<\/blockquote>\n

If there is a whole point to this blog post it\u2019s probably:<\/p>\n

The aspect of a CQRS system that benefits most from using the pattern is adding new ways to display, update and create existing entities. This is the one thing that typically doesn\u2019t happen in a CRUD system.<\/strong><\/p>\n

When applying CQRS to something that is 80% CRUD to all 100% of the application, you have not properly assessed the patterns\u2019 Applicability<\/code> nor its Intent<\/code> and are left only with its Consequences<\/code>:<\/p>\n

\"There<\/p>\n

An Explosion of Classes<\/h2>\n

A create and an update probably save to the same place in the same structure.<\/p>\n

So you need to do a mapping from 2 models to the \u201cdatabase\u201d structure. I\u2019m sure you have a mapper for that, so you now have 2 mappers. Oh and of course also 2 controllers, perhaps 2 services and also 2 validators. And 2 repositories and 2 dtos and 2 handlers and uhm do you not need a separate interface type for all these? We want to talk to an interface, not an implementation after all!<\/p>\n

Instead of a delete\/getOne just passing along an int id<\/code> we will now also introduce good old DeleteModelRequest<\/code> and GetModelByIdRequest<\/code>: Because who doesn\u2019t like a hundred classes with one int Id<\/code> field in them. Even if you don\u2019t want them, you\u2019ll probably end up with a package that requires a specific type per command for its wiring.<\/p>\n

So yeah, the amount of types in your application will grow. Dramatically.<\/p>\n

An Explosion of Duplication<\/h2>\n

Well since it\u2019s CRUD you are bound to be doing the exact same thing multiple times. Right.. not exactly the same thing of course, there is that one field\u2026 in which entity was it again?<\/p>\n

\"Duplication!?<\/p>\n