CQRS by Example (Introduction)

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)

Order GetOrder(OrderId)

Done! That is the whole CQRS pattern applied.

This simple separation enables us to do many interesting things from an 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.

Command

A Command is the only way to change the state of our system. Commands are responsible for introducing all changes to the system. Commands should not return any value.

Query

A 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 sorts of data transformations to deliver data 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.

Summary

With this first blog post about CQRS, we explored the fundamentals and some basic terms 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!

References

• 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/