CQRS, a different vision of the N-Tier architecture.

1. CQRS
Command Query Responsibility Segregation

2. What problems are we
trying to solve?

3. Once upon a time…

4. Paper was all around before the advent of computers

5. Then came our savior: the data entry screen

6. It’s a brave new world
No just about paper input anymore
But application architecture still reflects that idea
IT made it all about the data
Data centric apps are CRUD based

7. Insidious CRUD
This might be a good idea for catalog data type
But only for that type of application
How to change state with CRUD?
Read documentation?
Follow existing business process?
This feels so unnatural
If the domain model is the rules
Then don’t make the user be the domain model

8. Complexity of code and solution
Too many layers
Big data models
Anemic domain model
Focus on frameworks instead of on the domain
Scalability not considered at the core of the design
(scalability get hacked in too late)

9. Many perspectives on data

10. Typical one size fits all architecture

11. Which leads to maintainability issues

12. Monolithic and tighly coupled application
One does not simply draw a class diagram.

13. And poorly used tools
One SQL query to rule them all.

14. Good architects & layer best practices

15. Applications exist to support use cases
User intent to manipulate information
AKA a « mutator » (or setter)
User intent to find and read information
AKA an « accessor » (or getter)

16. CQRS
Functions that write (mutators) are called « Command » methods
They must not return a value
Functions that read (accessors) are called « Query » methods
They must have no side effects

17. Commands
Primary goal is to capture user intent
Supports a single use case and targets a single aggregate
Are imperative
CreateOrder
SendNotification
UnregisterConference
…

18. Queries
Query results contain only data, no logic
But there’s more about them…
I’ll tell you later on…
I promise!

19. Real life scenario
Alice reads
data
Bob reads
data
Oh, it’s coffee
time for Bob!
Alice update
data
Bob updates
stale data
KABOOM !
Optimistic Locking Exception

20. We’re always working with stale data
Think about your favorite browser
When the HTML page is rendered, several milliseconds have passed since the request was sent
The document could have changed on the server side
But you are OK with it
Think about the stars in the sky
When we observe one, several years have passed
The star has maybe exploded
But you are OK with it
This is what we call « eventual consistency »

21. Let’s use stale data to our advantage
Offload the database by using read models
Tailor each read models to match as close as possible the view to avoid mappings
Serve read models very quickly

22. So what is CQRS?
« CQRS is simply the creation of two objects
where there was previously only one. »
-- Greg Young

23. Queries
Query results contain only data, no logic
Query results are stale
Query operates on a completely denormalized data model
Query are fast and avoid as much as possible mappings and transformations

24. All we need is good synchronization

25. Events
Signal that something happened
Closely aligned to the domain model
Are handled by a messasing system
Are in the past tense
OrderCreated
NotificationSent
ConferenceUnregistered
…

26. Commands
Primary goal is to capture user intent
Supports a single use case and targets a single aggregate
Are imperative
CreateOrder
SendNotification
UnregisterConference
…
Mutate aggregate state which results in one or more events being published

27. Events as a source
It’s the ES (Event Sourcing) in CQRS/ES
Aggregate state is not stored as is
But rather the events that took place
Aggregate’s events represent its history
Built-in audit log
Any state can be rolled back
Snapshots can be taken when the event stream is big enough
A good example is your bank account

28. A typical sequence

29. References
Greg Young (@gregyoung)
Udi Dahan (@UdiDahan)
Martin Fowler (@martinfowler)