Rethink your architecture with CQRS
•
12 gostaram•2,420 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Semelhante a Rethink your architecture with CQRS
Semelhante a Rethink your architecture with CQRS (20)
Mais de Pieter Joost van de Sande
Último
Último (20)
Rethink your architecture with CQRS
- 1. Change the Rules Rethink you architecture with CQRS
- 2. Change the Rules Who are those guys? INTRODUCTION
- 5. Change the Rules Agenda • Introduction • Current architectures & problems • CQRS • Food for thought
- 7. Change the Rules Huidige architecturen bron: .NET Application Architecture Guide 2.0
- 8. Change the Rules Huidige architecturen 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 “A single model cannot be appropriate for reporting, searching, and transactional behaviors.” – Greg Young
- 13. Change the Rules “Doordat software processen kan automatiseren stelt het ons in staat deze verder op te schalen dan ooit tevoren.“
- 14. 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
- 15. Change the Rules Presentation layer 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 Here we go! FROM CONCEPT TO ARCHITECTUUR
- 22. Change the Rules User interface
- 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 “State transitions 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 Write side Read side Read databases Facade Commandhandlers commands DTO’s User interface
- 33. Change the Rules Command handler sample
- 34. Change the Rules The domain • Validates and handles commands • Encapsulates behavior • Build with rich object oriented techniques
- 35. Change the Rules Write side Read side Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface
- 36. Change the Rules Write side 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. Change the Rules Transitional flow
- 39. Change the Rules Write side Read side ? Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface
- 40. Change the Rules Write side Read side Denormalizers Event bus events events events Read databases Repository Domein Facade Commandhandlers commands DTO’s User interface
- 41. Change the Rules Denormalizer sample
- 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. Change the Rules Application flow
- 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’ve been a great audience!
- 57. Change the Rules Reference material • Podcast with Greg Young • MyShop reference architecture • Ncqrs framework • InfoQ: Unshackle Your Domain