Introducing CQRS and Event Sourcing with a Demo Application

| by Jan Stenberg Follow 34 Followers on Jun 08, 2015. Estimated reading time: 2 minutes |

When working with improving his understanding of the architecture and patterns involved in Command Query Responsibility Segregation (CQRS), Sacha Barber decided to create a CQRS demo application including event sourcing and an article explaining the inner workings.

Barber, a Microsoft C# MVP, describes CQRS as separating the responsibility of handling side-effect-free query or read access from the responsibility of handling command input. In his example he uses both separate models and separate storage for the write and read model respectively, a type that Vladimir Khorikov earlier defined as type three of CQRS. Barber defines event sourcing as a way of storing changes in application state as a sequence of events instead of just the current state. To get the current state of an object all events are retrieved and played in sequence on the object. This also makes it possible to reconstruct past state by replaying events up to a certain time and to adjust state with respect to retroactive changes.

Using an event based write model and separate storage for the two models means the read model will be updated by events from the write side. Doing this asynchronously means a change in state due to a command may not be reflected in an immediately following read, and Barber notes that the application now is eventually consistent. Due to this he believes that CQRS implemented in this quite typical way is not suitable for request/response type of operation where the user expects an immediate and correct response to a request. An operation where the command from a user perspective is clearly separated from a query is therefore for Barber a preferable use case for CQRS.

To improve the understanding of CQRS Barber has created a complete demo application built on the .NET platform comprising all parts of CQRS including event sourcing using an asynchronous approach with RabbitMQ as an interprocess bus between the write and read models. To simplify he has used in memory models where possible including the event store which means events are not persisted between runs. Building blocks of his application includes a command bus, a domain and an event store on the command side, an event bus and a NoSQL database, event handlers and a data layer on the read side.

A common opinion is that a CQRS Framework is often a hindrance but referring to his lack of experience with CQRS Barber has based his application on CQRSlite, an extension to an older framework created by Greg Young.

Barber’s demo application is available for download from GitHub.

Rate this Article

Adoption Stage

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
Community comments

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


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

Recover your password...


Follow your favorite topics and editors

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


More signal, less noise

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


Stay up-to-date

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