1 / 23

CQRS

CQRS. Command-Query Responsibility Segregation - scurt ă introducere , exemple - Tudor Turcu iQuest. CQRS – what?. Command-Query Respons a bility Segregation: principiu ‘ vechi ’, buzzword nou

vidal
Download Presentation

CQRS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CQRS Command-Query Responsibility Segregation -scurtăintroducere, exemple- Tudor Turcu iQuest

  2. CQRS – what? • Command-Query Responsability Segregation: principiu ‘vechi’, buzzword nou • Folosireaunui domain model pentruupdatareadatelor, separatde celfolositpentrucitirealor • Bertrand Meyer:CQS: Command and Query Separation Principle – o metodăartrebui să fie ori o comandăceexecută o acțiune, fie un query cereturnează date (interogări fără side-effects)

  3. Arhitectură „tipică” (C) Greg Young

  4. CQRS – why? • Ceproblemeduc la necesitateaaplicăriiacestui “pattern”? • Dificultatea aplicarii DDD in arhitecturile „clasice”: DTO, operatii CRUD • Data storage – limitează scalabilitatea • „Intentia” userului se pierde

  5. 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)

  6. „Behavioral Interface” (C) Greg Young

  7. 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

  8. „Command side” (C) Greg Young

  9. 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

  10. „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

  11. „Query side” (C) Greg Young

  12. „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)

  13. „Command side” (C) Greg Young

  14. Data storage separate (C) Greg Young

  15. Data storage separate Dezavantaje Avantaje • Dificultatea de a le menține sincronizate • Dificulatatea de a corecta o eroare la sincronizare • Eventual consistency • Scalabilitate / performanță

  16. Posibile soluții (command side) • Events / event sourcing • O comandă procesată cu success  event (s) • Reprezintă ceva ce s-a întămplat in trecut • similarecastructurăcu comenzile, dardiferite: • poatefi anulatdoarprintr-o altaactiune care sa-ianulezeefectele (compensate) • comenzileau 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”

  17. 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

  18. Events / snapshots

  19. 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

  20. CQRS + Event sourcing (C) Greg Young

  21. CQRS Sample https://github.com/MarkNijhof/Fohjin (Mark Nijhof – ‘Fohjin’)

  22. CQRS – more info • Greg Young – cqrsinfo.com • Martin Fowler - http://martinfowler.com/bliki/CQRS.html • Udi Dahan – Clarified CQRShttp://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/

  23. Questions ?

More Related