BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News CQRS as a Style of Thinking

CQRS as a Style of Thinking

Leia em Português

This item in japanese

Bookmarks

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
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.

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

Community comments

  • CQRS vs Differential Synchronization

    by Igor Kolomiets,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    So ???

  • Re: CQRS vs Differential Synchronization

    by Erik Gollot,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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

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

BT