DEV Community

Corey O'Connor
Corey O'Connor

Posted on

1

Questions to ask for CQRS

CQRS stands for "Command Query Responsibility Segregation". The idea is an extension of the single responsibility principle applied to services:

Command and Query are responsibilities of a system. By single responsibility principle, each of these responsibilities should be separate in the system.

"How tho?" As with all design principles: giving the definition does not teach how to apply the principle. :)

There are a lot of technologies that enable CQRS and these are worth an overview. I want to focus on the conceptual and logical first. The critical aspect of segregating command and query is useful even in design.

For instance, a useful question: "Does this change the state of the system?". This likely resembles asking about purity to functional programmers. Yep, same idea :) Just applied early and often in the design. We should aim for a clear answer: Yes or no. If there isn't a clear answer then that likely indicates a poor separation of command and query.

Is this an interesting topic for anybody else?

Do your career a big favor. Join DEV. (The website you're on right now)

It takes one minute, it's free, and is worth it for your career.

Get started

Community matters

Top comments (2)

Collapse
 
kspeakman profile image
Kasey Speakman •

I find CQRS pretty interesting. I wrote an article last year about some of our practices.

For me, CQRS answered a problem that I kept running into when I would create applications. Using 3 layer program structure, I always ended up with a bloated data model that shared concerns of both the presentation and business layers. It became harder to maintain over time as it became less clear which bits of data were important (read as: changes were breaking) to which layer. Because they were all housed in the same set of normalized tables. Even applying CQRS at a minimal level (for example, separate tables for business logic vs presentation, writing to both on save) helps to improve the situation.

The problem with learning about this practice is that it has been conglomerated with a lot of other things over time. So when you try to learn about it, you end up "drinking from the firehose" of myriad other dimensions around it (like DDD, event sourcing, eventual consistency, optimistic concurrency, etc). I also utilize most of these since they are progressive optimizations, but the pattern is usable without them. And the shift in thinking was too big for me to do all at once.

Collapse
 
coreyoconnor profile image
Corey O'Connor •

Great article! Thanks for sharing :)

AWS Security LIVE!

Tune in for AWS Security LIVE!

Join AWS Security LIVE! for expert insights and actionable tips to protect your organization and keep security teams prepared.

Learn More

👋 Kindness is contagious

Dive into an ocean of knowledge with this thought-provoking post, revered deeply within the supportive DEV Community. Developers of all levels are welcome to join and enhance our collective intelligence.

Saying a simple "thank you" can brighten someone's day. Share your gratitude in the comments below!

On DEV, sharing ideas eases our path and fortifies our community connections. Found this helpful? Sending a quick thanks to the author can be profoundly valued.

Okay