Don’t hack your model. Use CQRS! — Part I

Piotr Korlaga
Jan 21, 2018 · 4 min read

CQRS is (not?) that simple

When I was trying to learn what the heck is CQRS, I found it very difficult. Authors of blog posts, and others in their explanations, are constantly mixing CQRS with different buzzwords. This makes things not easy for understanding. Oh well, at least for me.

What really is CQRS?

You can describe the entire idea of CQRS in just a single sentence.

CQRS is separate model between write and read.

In this blog post, we will talk about pure CQRS. No event sourcing, no message patterns, no eventual consistency anymore. All these buzzwords make things complex. Despite that, my goal is to keep CQRS sweet and simple.

Let’s go deeper!

Traditional approach

The traditional way of system design is creating one model which is being updated by UI events. We have one database schema and corresponding application model. The same model for reading and writing. Simple enough, and frankly speaking, this works well! But let’s try to do that in a slightly different way.

CQRS to the rescue

Now we have two models instead of one common. First model perfectly matches writing purpose and the second one is designed to read data. In your application, you very often meet the situation when data is saved in some way but displaying in totally another. Being tied up to one model in an application is a big concern. Using CQRS simplifies things. Now you can structure your data models to your needs. No need to hack your common data model. Just use two! But that’s not the end…

More than one read model

It’s worth noticing that you can create multiple read model, not only one. Every one of them can have its own API that is isolated from the other. It helps us with keeping code architecture clear. And going further, we can have…

More than one data source

Separation of data sources is the thing that really decouples the problem. But we all know the reality. Requirements are not clear and constantly changing. It’s hard to design correct database schema from the very beginning, and changes in that model are costly. Don’t try to do everything perfectly from the start. Use evolution way to carve your architecture. Start with simple CQRS with one data source and when you will feel comfortable with domain understanding you can cut database to smaller parts and even use polyglot persistence if you need.

Enough with theory

That’s all for today. You know CQRS and how simple it can be. You know how to separate read from write, how to create multiple read models and how CQRS lets you use polyglot persistence. But talk is cheap. Enough with theory. Let’s jump to the code.

I created a very simple project on our GitHub. You can check it out right now or stay tuned and you will find my guide on this blog, next week. 🔜

Follow to not miss! 🚀

EDIT: Part 2 is available!


Tap the 👏 button if you found this article useful!

About us

Applantic is a team of passionated software developers. We write our stories on Medium ✍ but you can find us on Instagram 📷 or Facebook ✍ & 📷 as well.

The author of this article is Piotr. He is a software engineer — well-versed in all phases of the software development lifecycle. He strongly believe in being agile and engineering culture. You can find him on LinkedIn and GitHub.

Applantic

apps & more