Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introduction to CQRS

2,353 views

Published on

  • Be the first to comment

Introduction to CQRS

  1. 1. IntroductionCQRS Pieter Joost van de Sande
  2. 2. Thank you VSOFT!!
  3. 3. Agenda How we do things now What CQRS changes to that Building a CQRS architecture Some demo stuff Discussion Beer!
  4. 4. Typicalarchitectures You should recognize this
  5. 5. Typical architectures
  6. 6. Typical architectures Presentation Domain Data
  7. 7. N-Layer Flexible – we could replace a layer without breaking much. Simple separation that is easy to explain. Higher abstraction with each layer. Known by a lot of people. Supportedby tools andframeworks Lots of resources available
  8. 8. What the n-tier tunnel brought us
  9. 9. Typical architectures
  10. 10. TWO fundamental things Every system has this
  11. 11. data
  12. 12. Transitions
  13. 13. What is CQRS? COMMAND QUERY RESPONSIBILITY SEGREGATION
  14. 14. Cqrs Concept Move from N-layer to…
  15. 15. N-LAYERarchitecture Presentation Domain Data
  16. 16. Presentation Domain Data
  17. 17. Presentation Domain Data
  18. 18. Presentation Domain Data
  19. 19. Presentation Read State transitions Domain Data
  20. 20. fromCQRS Concepttoarchitecture This adds more value!
  21. 21. User interface
  22. 22. Demand for data Because we have some screens to fill
  23. 23. WE read a lot
  24. 24. WE have multiple screens to fill
  25. 25. Data should be close to us
  26. 26. Demandfor data User interface has different views tofill. It shouldnot have toexecute business rules on the data. It requests data manytimes. It shouldbe close tous. Getting data shouldbesimple (select * from x where y) Examples: Get all products of user X Get total price of all orders of month May
  27. 27. User interface
  28. 28. Read side User interface
  29. 29. Read side Read databases User interface
  30. 30. Read side Read databases query User interface
  31. 31. Read side The only need it has to serve is reading. Do we need an relational data here? Contains the data in an form we need Facades should be minimized Read models do not have to be on one location... They should be close to the client
  32. 32. Read side Read databases query User interface
  33. 33. Demand for change Otherwise things are static
  34. 34. I want to tell the system something Please move customer X to this new address
  35. 35. Change has intent Users don’t make changes for nothing. This intent has value! Correct the address for user X Customer X moved to new address VS.
  36. 36. Multiple steps Users can take multiple steps before they reach the end goal. These steps can be very useful to us.
  37. 37. Commands Model that is optimized the describe changes. Commands contain all the data needed to execute the underlying action. Contain the intent of the change. Examples: AddProductToShoppingCart PurchaseOrder MoveUserToNewAddress CorrectAddressForUser
  38. 38. Read side Read databases query User interface
  39. 39. Read side Write side Read databases query User interface
  40. 40. Read side Write side Read databases Commandhandlers commands query User interface
  41. 41. Read side Write side Read databases Facade Domain Commandhandlers commands DTO’s User interface
  42. 42. Greg Young: “State transitions are an important part of our problem space and should be modeled within our domain.”
  43. 43. The ‘old’ domain model
  44. 44. Domain focused on behavior
  45. 45. Read side Write side Read databases Facade Domain Commandhandlers commands DTO’s User interface
  46. 46. Read side Write side Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface
  47. 47. Read side Write side ? Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface
  48. 48. events All changes are captured by events. The read models keep themself up to date from it. Other systems use it for intergration. Examples ProductAddedToShoppingCart OrderPurchased UserMovedToNewAddress AddressCorrectedForUser
  49. 49. Eventual consistency Updates will eventually propagate through the system. This means we need to think differently about concurrency!
  50. 50. Read side Write side events Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface
  51. 51. Read side Write side Denormalizers events Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface
  52. 52. Denormalizers Will keep the read models up to date based on the event stream. An event can cause multiple updates.
  53. 53. Read side Write side events events Denormalizers Event bus events Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface
  54. 54. Event sourcing
  55. 55. Read side Write side events events Denormalizers Event bus events events Read databases Repository Facade Domain Commandhandlers commands DTO’s User interface
  56. 56. Event store Contains all events Contains the audit log Read models can re-build themself of it The domain uses it to build the current state
  57. 57. Final flow
  58. 58. CQRS Wrapup The domain receives commands and publishes domain events. Allstate changes are represented by domainevents The read models are updated as a resultof the published Events All Queries go directlyto the read models, the domain model is not involved
  59. 59. 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
  60. 60. NCQRS The CQRS framework for .NET
  61. 61. Thankyou!You’ve been a great audience!

×