Architecture Weekly

Architecture Weekly

Playback speed
×
Share post
Share post at current time
0:00
/
0:00
2
1

Webinar #4 - From CQRS to CRUD in Practice

Oskar Dudycz's avatar
Oskar Dudycz
Sep 27, 2022
2
1
Share

Technical patterns are filled with myths and mishaps. Quite often, this happens to CQS and CQRS.

Let’s start with these enigmatic acronyms.

CQS stands for Command Query Separation.

CQRS, Command Query Responsibility Segregation.

You can hear quite often that to use CQ(R)S:

  • You need two databases.

  • You have to use a messaging queue (e.g. RabbitMQ or Kafka).

  • It’s hard to apply and complicates the architecture.

  • You’ll be facing Eventual Consistency.

  • You need to do Event Sourcing.

Unfortunately, most of the material shows a skewed perspective about CQRS, not the original definition. CQRS is about separating behaviours in your architecture to writes and reads. It's about focusing on the business operations and ensuring that "writes" (so business logic) are separated from the read operations. That's not related to messaging, event sourcing, eventual consistency, etc. It's about making clear operation intentions and segregating them. I wrote longer about the common myths in my article:

During the webinar, we tackled those myths.

I showed how to start with the classical layered CRUD monolith and, step by step, go to the CQRS. I showed that you don’t need a fancy tech stack but focus on the business and slicing your architecture vertically to get more explicit and straightforward code.

See the full code in: https://github.com/oskardudycz/EventSourcing.NetCore.

Webinars:

© 2025 Oskar Dudycz
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture