Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Dino Esposito on CQRS, Messages and Events

Dino Esposito on CQRS, Messages and Events

Command Query Responsibility Segregation (CQRS) is the starting point of a change that will have a profound impact on system architecture, Dino Esposito claims in three articles in MSDN Magazine. It’s the first step in a longer evolution transitioning software architects from the idea of “models-to-persist” to the idea of “events-to-log”. He envisions that the next few years will primarily be about architecture, with event-based data as the primary data source instead of data snapshots.

Esposito, a Microsoft MVP since 2006, describes CQRS as a design style separating code that alters state from code that reads state. He emphasizes that simply recognizing that commands and queries are two different things may have an impact on software architecture, making it simpler to envision and code each part. The command side can focus on business rules while the query side’s only concern is returning data. The respective pipeline can also be optimized without risk of breaking the other one. The most basic form of CQRS separates writes and reads but uses one database. There are more advanced forms though, a subject Vladimir Khorikov wrote about earlier.

Esposito notes that many developers tend to apply CQRS only to collaborative and high-scale applications, but to him it’s an approach to software development that has benefits regardless of the perceived complexity of a system. Although CQRS excels in applications with a high degree of business complexity he thinks it’s a simple and powerful pattern also right for common, e.g. CRUD based, applications.

For Esposito the major benefit of a message-based architecture is that it simplifies managing complex and changing business workflows to support new scenarios. He notes that building a message-based system without using CQRS is very hard, if not impossible. By adding domain events workflows can be modelled in terms of individual actions, (triggered by commands), and events. Creating handlers taking care of commands and subsequent events the workflow is broken down into many small steps thereby simplifying changes of the workflow.

One aspect of a CRUD system that Esposito has found often goes unnoticed is that data stored is a snapshot; it’s the last known system state. With a request for a feature requiring the application clock to be moved backward, storing just snapshots can never fulfil that request. The only solution he sees in this scenario is to re-architect the system to save domain events, storing all changes in the domain. Storing data as events decreases the data abstraction level, giving the opportunity to use the same data for different purposes, including plain queries, business intelligence and usage analytics.

Rate this Article