CQRS Command-Query Responsibility - PowerPoint Presentation

Slide1

CQRS

Command-Query

Responsibility

Segregation

-

scurt

ă

introducere

,

exemple

-

Tudor

Turcu

iQuest

Slide2

CQRS – what?

Command-Query

Respons

a

bility

Segregation:

principiu

‘

vechi

’, buzzword

nou

Folosirea

unui

domain model

pentru

updatarea

datelor

,

separat

de

cel

folosit

pentru

citirea

lor

Bertrand Meyer

:

CQS:

Command

and Query Separation

Principle – o

metod

ă

ar

trebui

s

ă

fie

ori

o

comand

ă

ce

execut

ă

o ac

ț

iune

, fie un query

ce

returneaz

ă

date (

interog

ă

ri

f

ă

r

ă

side-effects)

Slide3

Arhitectură „tipică”

(C) Greg Young

Slide4

CQRS – why?

Ce

probleme

duc

la

necesitatea

aplic

ă

rii

acestui

“pattern”?

Dificultatea aplicarii DDD in arhitecturile „clasice”: DTO, operatii CRUD

Data storage – limitează scalabilitatea

„Intentia” userului se pierde

Slide5

CQRS – How?

Poate fi aplicat gradual, la diferite nivele în aplicație, în funcție de necesităti

Primul pas: separarea „query model” de domain model

Task-based UI

 command objects

Separarea se poate continua la toate layerele (inclusiv data storage)

Solutii de implentare (

optionale

): command handlers, event sourcing, separate read DB, command queues etc.

(nu fac parte din CQRS)

Slide6

„Behavioral

Interface

”

(C) Greg Young

Slide7

Commands

Reprezintă „intenția” userului (derivate din use cases)

Simplu obiect ce conține numele operației și datele necesare efectuarii operației

O comandă poate eșua (poate fi respinsă de application server)

Procesate de către command handlers:

Similare cu application services

Nu conțin business logic propriu

Fatadă la domain model

Slide8

„Command side”

(C) Greg Young

Slide9

CQRS

„

Command side”

„

Query side”

Data consistente (valide și actuale)

Data storage: tranzactional, normalizat

mai putine tranzactii, nu trebuie sa fie foarte scalabil

Permite (uneori) date care nu sunt actuale

Date denormalizate

Multe interogari, scalabilitate ridicata

Slide10

„Query” side

Poate sa

nu

folosească domain objects, ci DTOs

Nu necesită un O/RM

Poate folosi views sau stored procedures care să producă modelul denormalizat

Ușor de implementat (echipă separată, developeri mai puțin experimentați)

Scalabilitate

Slide11

„Query side”

(C) Greg Young

Slide12

„Command side”

Behaviour / DDD

Posibilă solutie:

Commands

 Domain model  DB relational/normalizat

Sau Command  Domain model  Events  Events storage

Data storage – separat de „query side”, sau nu

Avantaje:

Domain model-ul nu mai trebuie sa expuna stete-ul intern

Separation of concerns

(domain model-ul nu mai e folosit pentru query-uri)

Slide13

„Command side”

(C) Greg Young

Slide14

Data storage separate

(C) Greg Young

Slide15

Data storage separate

Dezavantaje

Avantaje

Dificultatea de a le menține sincronizate

Dificulatatea de a corecta o eroare la sincronizare

Eventual consistency

Scalabilitate / performanță

Slide16

Posibile soluții (command side)

Events / event sourcing

O comandă procesată cu success

 event (s)

Reprezintă ceva ce s-a întămplat in trecut

similare

ca

structur

ă

cu

comenzile

,

dar

diferite

:

poate

fi

anulat

doar

printr

-o

alta

actiune

care

sa-i

anuleze

efectele

(compensate)

comenzile

au

behaviour

î

nglobat

(evenimentele nu)

Pot fi stocate și starea sistemului reconstituită oricând pornind de la evenimente

 elimină necesitatea unui storage relațional/normalizat

„deltas”

Slide17

Event sourcing

Avantaje

Dezavantaje

Audit log built-in

„Behavioral model”

Scenarii „what-if”

Append-only

Versionare ușurată

Debugging mai facil

Scalabil

Partitionare orizontală

Elimină discrepanțele dintre relațional și obiectual

Probleme de performanță (rezolvate cu rolling snapshots)

Se pretează acolo unde DDD poate fi aplicat

 costuri/complexitate inerentă în aplicare

Limitat la query-uri gen: GetAggregateById(..)

Discrepanță intre events și read model

Slide18

Events / snapshots

Slide19

Event sourcing – implementare

Câte un event storage per aggregate

Există event storage-uri gata implementate

3

tabele:

Events

Aggregates

Snapshots –

create asincron de către un proces în background

Slide20

CQRS + Event sourcing

(C) Greg Young

Slide21

CQRS

Sample

https://

github.com/MarkNijhof/Fohjin

(Mark Nijhof – ‘Fohjin’)

Slide22

CQRS – more info

Greg Young –

cqrsinfo.com

Martin Fowler -

http://

martinfowler.com/bliki/CQRS.html

Udi Dahan – Clarified CQRS

http://www.udidahan.com/2009/12/09/clarified-cqrs

/

ElegantCode – CQRS a la Greg Young:

http://elegantcode.com/2009/11/11/cqrs-la-greg-young

/

DDD/CQRS Google Group:

http://

groups.google.com/group/dddcqrs

Other CQRS resources:

http://www.thedeveloperday.com/cqrs-resources

/

Martin Fowler

–

Event sourcing:

http

://

martinfowler.com/eaaDev/EventSourcing.html

Articole ce descriu sample-ul:

http://elegantcode.com/2009/11/11/cqrs-la-greg-young/

Slide23

Questions

?