The Command Query Responsibility Segregation (CQRS) pattern isolates the data querying aspects of an application from the insert, update and delete operations. There are limited use cases regarding when you should use this pattern and it doesn’t apply to request response style scenarios where the updated results may need to be displayed to the user immediately after an insert / update / delete. You must carefully evaluate your requirements to determine if CQRS is suitable to address your architectural requirements. Typically, requirements that are more sophisticated than just information systems driven CRUD operations, such as information in different transient states of representation, are good candidates for CQRS.
Event Sourcing is a useful scenario where the CQRS pattern can be leveraged. In an event sourcing scenario, the application stores state transitions as events in an event store. The read and write models in the scenario may be in different states, but the application eventually gets a consistent current state by playing the events in sequence. A good example is a highly scalable hotel reservation system in which certain attributes of the reservation can be modified until midnight of the day before arrival. The query and command operations in this scenario can be dealt with separately using the CQRS pattern where the states maybe not in sync but will eventually become consistent to determine the current state of the reservation.
CQRSLite?is a useful and lightweight CQRS and Event Sourcing framework to start getting your head wrapped around the pattern. To create a more robust architecture around the CQRS pattern, often adding a complex event processing (CEP) tool or a bus is useful. Event Store?is an open source, high performance, scalable and highly available CEP written in JavaScript. Client interfaces are also provided in .NET apart from native HTTP.
