Change the Rules

Rethink you architecture with

CQRS

Change the Rules

INTRODUCTION

Who are those guys?

Change the Rules

Change the Rules

Change the Rules

Agenda

• Introduction

• Current architectures & problems

• CQRS

• Food for thought

Change the Rules

Change the Rules

Huidige architecturen

bron: .NET Application Architecture Guide 2.0

Change the Rules

Huidige architecturen Presentation layer

Application layer

Data layer

Change the Rules

multi-tier

Presentation layer

Domain layer

Data layer

Change the Rules

Presentation layer

Data layer

Domain layer

Request DTO

Map DTO

RequestDTO

Map DTO

Query data Query data

Update DTO

Map DTO

Query data Query data

RequestDTO

Change the Rules

Presentation layer

Data layer

Domain layer Send DTO

Send DTO

Map DTO

Map DTO

Write data Write data

Map DTO

Write data Write data

Send DTO

Request DTO

Map DTO

RequestDTO

Map DTO

Query data Query data

Update DTO

Map DTO

Query data Query data

RequestDTO

Change the Rules

“A single model cannot be appropriate for reporting, searching, and transactional behaviors.” – Greg Young

Change the Rules

“Doordat software processen kan automatiseren stelt het ons in staat deze verder op te schalen dan ooit tevoren.“

Change the Rules

“Every method should either be a command that performs an action, or a query that returns data to the caller, but not both.” – Bertrand Meyer

Change the Rules

Presentation layer

Domain layer

Data layer

Change the Rules

Presentation layer

Domain layer Data layer

Change the Rules

Presentation layer

Domain layer Data layer

Change the Rules

Presentation layer

Domain layer Data layer

Read focus State transition focus

Change the Rules

Presentation layer

Domain layer Data layer

Read focus State transition focus Queries Commands

Change the Rules

Presentation layer

Domain layer Read layer

Read focus State transities focus Commands Queries

Change the Rules

FROM CONCEPT TO ARCHITECTUUR

Here we go!

Change the Rules

User interface

Change the Rules

Queries

• Requests information

• Is context dependant

• Is executed many times

• Should be simple (select * from x where y)

• Examples:

– Get all products for user X

– Get total price of all orders of month May

Change the Rules

User interface

Read side

Change the Rules

Read side

User interface

Read databases

Change the Rules

Read side

User interface

Read databases

Facade

Change the Rules

Read side

User interface

Facade

Read databases

DTO’s

Change the Rules

Read side

• Focus on data needs

• Optimized for reading

• Can contain multiple models if needed

• Can be denormalized

• Facades should be minimized

Change the Rules

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

Change the Rules

Commands

• Causes a state transition

• Contains the intend of the user

• Exists in a bounded context

• Examples:

– AddProductToShoppingCart

– PurchaseOrder

– MoveUserToNewAddress

– CorrectAddressForUser

Change the Rules

Commands example

Create Cart

Add item Add item Add item Remove

item Purchase

Change the Rules

User interface

Commandhandlers

Read databases

Read side

commands DTO’s

Write side

Facade

Change the Rules

Command handler sample

Change the Rules

The domain

• Validates and handles commands

• Encapsulates behavior

• Build with rich object oriented techniques

Change the Rules

User interface

Commandhandlers

Read databases

Read side

commands DTO’s

Do

mei

n

Write side

Repository

Facade

Change the Rules

User interface

Commandhandlers

Read databases

Read side

commands DTO’s

Do

mei

n

Write side

Repository

?

Facade

Change the Rules

Domain events

• Result of a command

• Represents a event

• Examples

– ProductAddedToShoppingCart

– OrderPurchased

– UserMovedToNewAddress

– AddressCorrectedForUser

Change the Rules

Transitional flow

Change the Rules

User interface

Commandhandlers

Read databases

Read side

commands DTO’s

Do

mei

n

Write side

Repository

?

Facade

Change the Rules

User interface

Commandhandlers

Repository

Event b

us

Den

orm

aliz

ers

Read databases

Write side Read side

events

events events

commands DTO’s

Do

mei

n

Facade

Change the Rules

Denormalizer sample

Change the Rules

User interface

Commandhandlers

Repository

Event b

us

Den

orm

aliz

ers

Read databases

Write side Read side

events

events events

commands DTO’s

Do

mei

n

Event store

events

Facade

Change the Rules

Event store

• Contains all domain events

• Does not need to be relational

• Contains the audit log

• Read models can (re)build themself of it

• The domain uses it to get the current state

Change the Rules

queue

User interface

Commandhandlers

Repository

Event b

us

Den

orm

aliz

ers

Event store Read databases

Write side Read side

events

events

events events

commands DTO’s

Do

mei

n

Facade

Change the Rules

Application flow

Change the Rules

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

Change the Rules

Benefits

• Fully encapsulated domain that only

exposes behavior

Change the Rules

Benefits

• Fully encapsulated domain that only

exposes behavior

• Keep users intent

Change the Rules

Benefits

• Fully encapsulated domain that only

exposes behavior

• Keep users intent

• Bullet-proof auditing and historical tracing

Change the Rules

Benefits

• Fully encapsulated domain that only

exposes behavior

• Keep users intent

• Bullet-proof auditing and historical tracing

• No object-relational impedance mismatch

Change the Rules

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

Change the Rules

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

Change the Rules

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

Change the Rules

Consequences

• Learning curve

• Overhead for simple CRUD

• Data duplication

• Introducing an new architecture has a big

impact

Change the Rules

Food for thought

• Should your read model even contains a

relational database?

• What does this mean for requirement

engineering?

• What does this mean for outsourcing?

• What does this mean for DBA?

Change the Rules

You’ve been a great audience!

Change the Rules

Reference material

• Podcast with Greg Young

• MyShop reference architecture

• Ncqrs framework

• InfoQ: Unshackle Your Domain