Download as PDF, PPTX
Uploaded byPieter Joost van de Sande
Rethink your architecture with CQRS
The document discusses CQRS (Command Query Responsibility Segregation), an architectural pattern that separates read and write operations into different models. It outlines the benefits of CQRS such as encapsulating domain logic, optimized querying, and improved testability and auditing. The key aspects of CQRS covered include commands, events, read models, write models, and event sourcing. While CQRS has advantages, it also has learning challenges and overhead for simple applications. Food for thought questions are also raised about requirements, outsourcing, and database administration with this pattern.
More Related Content
Similar to Rethink your architecture with CQRS
Rethink your architecture with CQRS
- 1. Change the Rules Rethinkyou architecture with CQRS
- 2. Change the Rules Whoare those guys? INTRODUCTION
- 3.
- 4.
- 5. Change the Rules Agenda • Introduction • Current architectures & problems • CQRS • Food for thought
- 6.
- 7. Change the Rules Huidigearchitecturen bron: .NET Application Architecture Guide 2.0
- 8. Change the Rules Huidigearchitecturen Presentation layer Application layer Data layer
- 9. Change the Rules multi-tier Presentation layer Domain layer Data layer
- 10. Change the Rules Update DTO Presentation layer Request DTO Map DTO Domain layer Request Request DTO DTO Map DTO Map DTO Data layer Query data Query data Query data Query data
- 11. Change the Rules Update DTO Presentation layer Request Send DTO DTO Map DTO Map DTO Domain layer Request Request Send Send DTO DTO DTO DTO Map DTO Map DTO Map DTO Map DTO Data layer Query data Query data Query data Query data Write data Write data Write data Write data
- 12. Change the Rules “Asingle model cannot be appropriate for reporting, searching, and transactional behaviors.” – Greg Young
- 13. Change the Rules “Doordatsoftware processen kan automatiseren stelt het ons in staat deze verder op te schalen dan ooit tevoren.“
- 14. Change the Rules “Everymethod should either be a command that performs an action, or a query that returns data to the caller, but not both.” – Bertrand Meyer
- 15. Change the Rules Presentationlayer Domain layer Data layer
- 16. Change the Rules Presentation layer Data layer Domain layer
- 17. Change the Rules Presentation layer Data layer Domain layer
- 18. Change the Rules Presentation layer Read focus State transition focus Data layer Domain layer
- 19. Change the Rules Presentation layer Queries Commands Read focus State transition focus Data layer Domain layer
- 20. Change the Rules Presentation layer Queries Commands Read focus State transities focus Read layer Domain layer
- 21. Change the Rules Herewe go! FROM CONCEPT TO ARCHITECTUUR
- 22. Change the Rules Userinterface
- 23. 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
- 24. Change the Rules Read side User interface
- 25. Change the Rules Read side Read databases User interface
- 26. Change the Rules Read side Read databases Facade User interface
- 27. Change the Rules Read side Read databases Facade DTO’s User interface
- 28. 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
- 29. Change the Rules “Statetransitions are an important part of our problem space and should be modeled within our domain.” – Greg Young
- 30. Change the Rules Commands • Causes a state transition • Contains the intend of the user • Exists in a bounded context • Examples: – AddProductToShoppingCart – PurchaseOrder – MoveUserToNewAddress – CorrectAddressForUser
- 31. Change the Rules Commands example Create Remove Add item Add item Add item Purchase Cart item
- 32. Change the Rules Writeside Read side Read databases Facade Commandhandlers commands DTO’s User interface
- 33. Change the Rules Commandhandler sample
- 34. Change the Rules The domain • Validates and handles commands • Encapsulates behavior • Build with rich object oriented techniques
- 35. Change the Rules Writeside Read side Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface
- 36. Change the Rules Writeside Read side ? Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface
- 37. Change the Rules Domain events • Result of a command • Represents a event • Examples – ProductAddedToShoppingCart – OrderPurchased – UserMovedToNewAddress – AddressCorrectedForUser
- 38.
- 39. Change the Rules Writeside Read side ? Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface
- 40. Change the Rules Writeside Read side Denormalizers Event bus events events events Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface
- 41.
- 42. Change the Rules Write side Read side Denormalizers Event bus events events events events Event store Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface
- 43. 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
- 44. Change the Rules Write side Read side Denormalizers Event bus events events events events queue Event store Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface
- 45.
- 46. 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
- 47. Change the Rules Benefits • Fully encapsulated domain that only exposes behavior
- 48. Change the Rules Benefits • Fully encapsulated domain that only exposes behavior • Keep users intent
- 49. Change the Rules Benefits • Fully encapsulated domain that only exposes behavior • Keep users intent • Bullet-proof auditing and historical tracing
- 50. 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
- 51. 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
- 52. 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
- 53. 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
- 54. Change the Rules Consequences • Learning curve • Overhead for simple CRUD • Data duplication • Introducing an new architecture has a big impact
- 55. 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?
- 56. Change the Rules You’vebeen a great audience!
- 57. Change the Rules Reference material • Podcast with Greg Young • MyShop reference architecture • Ncqrs framework • InfoQ: Unshackle Your Domain