Introduction to CQRS
Download as PPTX, PDF3 likes1,708 views
This document provides an introduction and overview of CQRS (Command Query Responsibility Segregation). It discusses typical N-layer architectures and how CQRS changes the architecture by separating read and write operations. The key points are that CQRS moves the system from an N-layer to separating read and write concerns, with commands handling changes, events capturing changes, and read models optimized for queries and kept in sync with events. The document outlines the full flow from commands to events to updating read models and queries against the read models.
More Related Content
Viewers also liked (13)
Similar to Introduction to CQRS (20)
More from Pieter Joost van de Sande (13)
Introduction to CQRS
- 1. IntroductionCQRSPieter Joost van de Sande
- 4. AgendaHow we do things now
- 5. What CQRS changes to that
- 6. Building a CQRS architecture
- 8. Discussion
- 12. N-LayerFlexible – we could replace a layer without breaking much.
- 13. Simple separation that is easy to explain.
- 14. Higher abstraction with each layer.
- 15. Known by a lot of people.
- 17. Lots of resources availableWhat the n-tier tunnel brought us
- 19. TWO fundamental thingsEvery system has this
- 20. data
- 21. Transitions
- 23. Cqrs ConceptMove from N-layer to…
- 29. fromCQRS ConcepttoarchitectureThis adds more value!
- 31. User interface
- 32. Demand for dataBecause we have some screens to fill
- 33. WE read a lot
- 34. WE have multiple screens to fill
- 35. Data should be close to us
- 36. Demandfor dataUser interface has different views tofill.
- 37. It shouldnot have toexecute business rules on the data.
- 38. It requests data manytimes.
- 39. It shouldbe close tous.
- 40. Getting data shouldbesimple (select * from x where y)Examples:Get all products of user XGet total price of all orders of month May
- 41. User interface
- 43. Read sideRead databasesUser interface
- 44. Read sideRead databasesqueryUser interface
- 45. Read sideThe only need it has to serve is reading.Do we need an relational data here?
- 46. Contains the data in an form we need
- 47. Facades should be minimized
- 48. Read models do not have to be on one location...
- 49. They should be close to the clientRead sideRead databasesqueryUser interface
- 50. Demand for changeOtherwise things are static
- 51. I want to tell the system somethingPlease move customer X to this new address
- 52. Change has intentUsers don’t make changes for nothing.This intent has value!Correct the address for user XCustomer X moved to new addressVS.
- 53. Multiple stepsUsers can take multiple steps before they reach the end goal. These steps can be very useful to us.
- 54. CommandsModel that is optimized the describe changes.
- 55. Commands contain all the data needed to execute the underlying action.
- 56. Contain the intent of the change.Examples:AddProductToShoppingCartPurchaseOrderMoveUserToNewAddressCorrectAddressForUser
- 57. Read sideRead databasesqueryUser interface
- 58. Read sideWrite sideRead databasesqueryUser interface
- 59. Read sideWrite sideRead databasesCommandhandlerscommandsqueryUser interface
- 60. Read sideWrite sideRead databasesFacadeDomainCommandhandlerscommandsDTO’sUser interface
- 61. Greg Young:“State transitions are an important part of our problem space and should be modeled within our domain.”
- 62. The ‘old’ domain model
- 63. Domain focused on behavior
- 64. Read sideWrite sideRead databasesFacadeDomainCommandhandlerscommandsDTO’sUser interface
- 65. Read sideWrite sideRead databasesRepositoryFacadeDomainCommandhandlerscommandsDTO’sUser interface
- 66. Read sideWrite side?Read databasesRepositoryFacadeDomainCommandhandlerscommandsDTO’sUser interface
- 67. eventsAll changes are captured by events.The read models keep themself up to date from it.
- 68. Other systems use it for intergration.ExamplesProductAddedToShoppingCartOrderPurchasedUserMovedToNewAddressAddressCorrectedForUser
- 69. Eventual consistencyUpdates will eventually propagate through the system.
- 70. This means we need to think differently about concurrency!Read sideWrite sideeventsRead databasesRepositoryFacadeDomainCommandhandlerscommandsDTO’sUser interface
- 71. Read sideWrite sideDenormalizerseventsRead databasesRepositoryFacadeDomainCommandhandlerscommandsDTO’sUser interface
- 72. DenormalizersWill keep the read models up to date based on the event stream.
- 73. An event can cause multiple updates.Read sideWrite sideeventseventsDenormalizersEvent buseventsRead databasesRepositoryFacadeDomainCommandhandlerscommandsDTO’sUser interface
- 74. Event sourcing
- 75. Read sideWrite sideeventseventsDenormalizersEvent buseventseventsRead databasesRepositoryFacadeDomainCommandhandlerscommandsDTO’sUser interface
- 76. Event storeContains all events
- 77. Contains the audit log
- 78. Read models can re-build themself of it
- 79. The domain uses it to build the current stateFinal flow
- 80. CQRS WrapupThe domain receives commands and publishes domain events.
- 81. Allstate changes are represented by domainevents
- 82. The read models are updated as a resultof the published Events
- 83. All Queries go directlyto the read models, the domain model is not involvedBenefitsFully encapsulated domain that only exposes behavior
- 85. Bullet-proof auditing and historical tracing
- 86. No object-relational impedance mismatch
- 87. Optimized and multiple read models
- 88. Testability
- 89. Easy integration with external systemsNCQRSThe CQRS framework for .NET
- 90. Thankyou!You’ve been a great audience!