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.