INTRODUCTION

CQRS

PIETER JOOST VAN DE SANDE

THANK YOU VSOFT!!

AGENDA• How we do things now

• What CQRS changes to that

• Building a CQRS architecture

• Some demo stuff

• Discussion

• Beer!

TYPICALARCHITECTURES

YOU SHOULD RECOGNIZE THIS

TYPICAL ARCHITECTURES

TYPICAL ARCHITECTURES

Presentation

Domain

Data

N-LAYER• Flexible – we could replace a layer without breaking much.

• Simple separation that is easy to explain.

• Higher abstraction with each layer.

• Known by a lot of people.

• Supported by tools and frameworks

• Lots of resources available

WHAT THE N-TIER TUNNEL BROUGHT US

TYPICAL ARCHITECTURES

TWO FUNDAMENTAL THINGS

EVERY SYSTEM HAS THIS

DATA

TRANSITIONS

WHAT IS CQRS?

COMMAND

QUERY

RESPONSIBILITY

SEGREGATION

CQRS CONCEPT

MOVE FROM N-LAYER TO…

N-LAYERARCHITECTURE

Presentation

Domain

Data

Presentation

Domain

Data

Presentation

DomainData

Presentation

DomainData

Read State transitions

Presentation

DomainData

FROMCQRS CONCEPTTOARCHITECTURE

THIS ADDS MORE VALUE!

User interface

DEMAND FOR DATA

BECAUSE WE HAVE SOME SCREENS TO FILL

WE READ A LOT

WE HAVE MULTIPLE SCREENS TO FILL

DATA SHOULD BE CLOSE TO US

DEMAND FOR DATA• User interface has different views to fill.

• It should not have to execute business rules on the data.

• It requests data many times.

• It should be close to us.

• Getting data should be simple (select * from x where y)

Examples:

• Get all products of user X• Get total price of all orders of month May

User interface

User interface

Read side

Read side

User interface

Read databases

Read side

User interface

Read databases

query

READ SIDE

The only need it has to serve is reading.

• Do we need an relational data here?

• Contains the data in an form we need

• Facades should be minimized

• Read models do not have to be on one location...

• They should be close to the client

Read side

User interface

Read databases

query

DEMAND FOR CHANGE

OTHERWISE THINGS ARE STATIC

I WANT TO TELL THE SYSTEM SOMETHING

Please move customer X to this new address

CHANGE HAS INTENT

Users don’t make changes for nothing.

This intent has value!

Correct the address for user X

Customer X moved to new addressVS.

MULTIPLE STEPS

Users can take multiple steps before they reach the end goal. These steps can be very useful to us.

Create Cart Add item Add item Add item Remove

item Purchase

COMMANDS• Model that is optimized the describe changes.

• Commands contain all the data needed to execute the underlying action.

• Contain the intent of the change.

Examples:

• AddProductToShoppingCart• PurchaseOrder• MoveUserToNewAddress• CorrectAddressForUser

Read side

User interface

Read databases

query

Write side Read side

User interface

Read databases

query

Commandhandlers

commands

Write side Read side

User interface

Read databases

query

User interface

Commandhandlers

Read databases

Read side

commands DTO’s

Dom

ain

Write side

Facade

GREG YOUNG:

“State transitions are an important part of our problem space and should be modeled within our domain.”

THE ‘OLD’ DOMAIN MODEL

DOMAIN FOCUSED ON BEHAVIOR

User interface

Commandhandlers

Read databases

Read side

commands DTO’s

Dom

ain

Write side

Facade

User interface

Commandhandlers

Read databases

Read side

commands DTO’s

Dom

ain

Write side

Repository

Facade

User interface

Commandhandlers

Read databases

Read side

commands DTO’s

Dom

ain

Write side

Repository

Facade

?

EVENTS

All changes are captured by events.

• The read models keep themself up to date from it.

• Other systems use it for intergration.

Examples

• ProductAddedToShoppingCart• OrderPurchased• UserMovedToNewAddress• AddressCorrectedForUser

EVENTUAL CONSISTENCY• Updates will eventually propagate through the system.

• This means we need to think differently about concurrency!

User interface

Commandhandlers

RepositoryRead databases

Write side Read side

eventscommands DTO’s

Dom

ain

Facade

User interface

Commandhandlers

Repository

Den

orm

alize

rs

Read databases

Write side Read side

eventscommands DTO’s

Dom

ain

Facade

DENORMALIZERS

• Will keep the read models up to date based on the event stream.

• An event can cause multiple updates.

User interface

Commandhandlers

Repository

Event bus

Den

orm

alize

rs

Read databases

Write side Read side

events

events events

commands DTO’s

Dom

ain

Facade

EVENT SOURCING

User interface

Commandhandlers

Repository

Event bus

Den

orm

alize

rs

Read databases

Write side Read side

events

events events

commands DTO’s

Dom

ain

Facade

events

EVENT STORE

• Contains all events

• Contains the audit log

• Read models can re-build themself of it

• The domain uses it to build the current state

FINAL FLOW

CQRS WRAPUP• The domain receives commands and publishes domain

events.

• All state changes are represented by domain events

• The read models are updated as a result of the published Events

• All Queries go directly to the read models, the domain model is not involved

BENEFITS• Fully encapsulated domain that only exposes behavior

• Keep users intent

• Bullet-proof auditing and historical tracing

• No object-relational impedance mismatch

• Optimized and multiple read models

• Testability

• Easy integration with external systems

NCQRS

THE CQRS FRAMEWORK FOR .NET

THANK YOU!YOU’VE BEEN A GREAT AUDIENCE!