I’m doing some R&D for a future project at work and I’m currently exploring some architectural prototypes. In the last few weeks I explored the CQRS pattern.
CQRS thanks to the separation of the read/query services from the action/command services enables us to do many things.
At a very basic level applying CQRS means something like this (in psuedo-code).
void Ship(OrderId) Order GetOrder(OrderId) void ChangeOrderShipmentAddress(OrderId, NewAddress) void CreateOrder(Order) void ChangeOrderPaymentMethod(OrderId, PaymentMethod)
Applying CQRS on this would result in two services:
void Ship(OrderId) void ChangeOrderShipmentAddress(OrderId, NewAddress) void CreateOrder(Order) void ChangeOrderPaymentMethod(OrderId, PaymentMethod)
Done! That is the whole CQRS pattern applied.
This simple separation enables us to do many interesting things from the architectural point of view. This means that the data models used for querying and updates can be different. They can stay in the same data store or be completely different.
A Command is the only way to change the state of our system. Commands are responsible for introducing all changes to the system. Command should not return any value.
Query is a read-only operation. With a query we read the state of a part of our system. We can do filters, projections and all sort of data transformation to deliver it to the UI in the most useful format. A query does not modify the state of our system. It can be run many times without side-effects.
With this first blog post about CQRS we explored the fundamentals and some basic terminology of the pattern.
In the next blog posts we’ll write some code to practice the implementation of such a pattern and get our hands dirty! 🙂
Microsoft Docs – https://docs.microsoft.com/en-us/azure/architecture/patterns/cqrs
Martin Fowler – https://martinfowler.com/bliki/CQRS.html
Greg Young – http://codebetter.com/gregyoung/2010/02/16/cqrs-task-based-uis-event-sourcing-agh/