BT

CQRS as a Style of Thinking

| by Jan Stenberg Follow 28 Followers on Nov 20, 2014. Estimated reading time: 2 minutes |

A note to our readers: You asked so we have developed a set of features that allow you to reduce the noise: you can get email and web notifications for topics you are interested in. Learn more about our new features.

A common context for Command-Query Responsibility Segregation (CQRS) is a collaborative domain with multiple users working on the same set of data, Udi Dahan explained when discussing CQRS in an interview. For Udi, an authority on service-oriented architecture and creator of NServiceBus, CQRS is an approach or a style of thinking, more than a pattern. When called a pattern it often becomes associated with only the solution part, the context part is too often forgotten, despite it being the most important part when discussing CQRS.

A lot of applications contain a business domain that is relatively simple with a user working on a piece of data with no one else working on the same data, meaning the user expects to directly read what they just wrote. Working with CQRS, and eventual consistency, in such a domain means you will be working hard trying to recreate what the end user really wants to see, an example of how important the context is working with CQRS and when it’s not suitable. In contrast, when in a collaborative domain with users modifying some data they have no way of knowing whether somebody else has also modified the same data and therefore their expectation of what they will be reading is different than in a single-user domain.

Usually collaborative domains tend to be large in number of records, each relatively small but resulting in a large data volume, with a lot of history and interaction. A classic example is the domain of inventory, with shipments coming in, purchases going out, and with questions like how large the stock is, how much can be purchased and delivery time for an order. A more high volume example is stock purchases, a domain that from the ground up is designed for handling large volumes and modelled for working with multiple parties.

Udi specifically notes that the intent never has been to build CQRS systems. CQRS will never be applicable to a whole application; part of it may be for single user doing CRUD, with other parts more collaborative and suitable for CQRS.

Today Udi puts a much stronger emphasize on data modelling. He thinks that ORMs has done some harm in making developers focusing entirely on their in-memory object model, not caring at all about the actual data model behind the scene. He states that in a collaborative domain you have to work the other way around, starting with the data model. He sees himself as a DDD guy but believes that sometimes you have to wait with the domain model and focus on the data modelling. In his experience this very often the leads to a data model being simple enough to question if a domain model is really needed.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

CQRS vs Differential Synchronization by Igor Kolomiets

I wonder how alternative in "collaborative domain" such as Differential Synchronization compares to CQRS. DiffSync has been recently given a boost by Spring's (still experimental?) Sync project: spring.io/blog/2014/10/22/introducing-spring-sync

so what ? by Erik Gollot

So ???

Re: CQRS vs Differential Synchronization by Erik Gollot

To my understanding spring sync is for...synchronization and updates. If you apply cqrs principles you can be obliged to synchronize multiple views of the same domain.
To go back to cqrs, it is not new that update and query models can be different. We all know database views, database materialized views and also reporting ready databases. Even if we do not have different physical structures we at least have logical ones. The performance problem and ease to create query solved by physical views raise the problem of synchronization

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

3 Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT