CQRSCommand Query Responsibility Segregation

What problems are wetrying to solve?

Once upon a time…

Paper was all around before the advent of computers

Then came our savior: the data entry screen

It’s a brave new worldNo 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

Insidious CRUDThis 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 rulesThen don’t make the user be the domain model

Complexity of code and solutionToo 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)

Many perspectives on data

Typical one size fits all architecture

Which leads to maintainability issues

Monolithic and tighly coupled applicationOne does not simply draw a class diagram.

And poorly used toolsOne SQL query to rule them all.

Good architects & layer best practices

Applications exist to support use casesUser intent to manipulate information

AKA a « mutator » (or setter)

User intent to find and read informationAKA an « accessor » (or getter)

CQRSFunctions that write (mutators) are called « Command » methods

They must not return a value

Functions that read (accessors) are called « Query » methodsThey must have no side effects

CommandsPrimary goal is to capture user intent

Supports a single use case and targets a single aggregate

Are imperativeCreateOrder

SendNotification

UnregisterConference

…

QueriesQuery results contain only data, no logic

But there’s more about them…

I’ll tell you later on…

I promise!

Real life scenario

Alice reads

data

Bob reads

data

Oh, it’s coffee

time for Bob!

Alice update

data

Bob updates

stale dataKABOOM !

Optimistic Locking Exception

We’re always working with stale dataThink 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 skyWhen 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 »

Let’s use stale data to our advantageOffload 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

So what is CQRS?« CQRS is simply the creation of two objects

where there was previously only one. »-- Greg Young

QueriesQuery 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

All we need is good synchronization

EventsSignal that something happened

Closely aligned to the domain model

Are handled by a messasing system

Are in the past tenseOrderCreated

NotificationSent

ConferenceUnregistered

…

CommandsPrimary goal is to capture user intent

Supports a single use case and targets a single aggregate

Are imperativeCreateOrder

SendNotification

UnregisterConference

…

Mutate aggregate state which results in one or more events being published

Events as a sourceIt’s the ES (Event Sourcing) in CQRS/ES

Aggregate state is not stored as isBut rather the events that took place

Aggregate’s events represent its historyBuilt-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

A typical sequence

ReferencesGreg Young (@gregyoung)

Udi Dahan (@UdiDahan)

Martin Fowler (@martinfowler)