Introduction to CQRS - command and query responsibility segregation
•Transferir como PPTX, PDF•
14 gostaram•3,525 visualizações
A high level introduction to CQRS (command and query responsibility segregation), CQS (command query separation), DDD (domain driven design), DDD-D ...with distributed, and how all those weave together.
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (18)
Semelhante a Introduction to CQRS - command and query responsibility segregation
Semelhante a Introduction to CQRS - command and query responsibility segregation (20)
Mais de Andrew Siemer
Mais de Andrew Siemer (10)
Último
Último (20)
Introduction to CQRS - command and query responsibility segregation
- 1. CQRS Command & Query Responsibility Segregation
- 2. Andrew Siemer http://about.me/andrewsiemer ASP Insider Microsoft V-TSP Father of 6 Jack of all trades, master of some.
- 4. We are hiring!!!
- 5. CQRS “…two objects where there previously was one!”
- 6. CQRS “Segregate operations that read data from operations that update data by using separate interfaces. This pattern can maximize performance, scalability, and security; support evolution of the system over time through higher flexibility; and prevent update commands from causing merge conflicts at the domain level.”
- 7. Goals • Introduction • Up to speed on the concepts • Won’t be an expert after this talk • But will be able to identify your next steps
- 8. What CQRS is not • Not a framework • Not an architecture • Not a specific tool • Not a BEST PRACTICE
- 9. Not a best practice • I always start the CQRS conversation with “THIS IS LIKELY NOT FOR YOU” • CQRS is great when it is justifiably needed • Due to high complexity, not a buzz word you want “just cause”
- 10. What CQRS is • CQRS is a pattern • CQRS ends up being a composition of tools and concepts • No two CQRS implementations are identical
- 11. How we got to the CQRS pattern • CQS was a good enough pattern • DDD made sense and became popular • DDDD: the 4th “D” represents Distributed as apps got bigger • Greg Young first to name CQRS • Others to get behind it • Udi Dahan • Eric Evans • Martin Fowler
- 12. In case you fall asleep Super quick take aways…
- 13. Traditional Standard three tier app, everything goes in and out
- 14. CQS Command Query Separation C Q
- 15. CQRS Command & Query Responsibility Segregation C Q
- 16. Data BL UI Traditional
- 17. Data BL UI CQS C Q
- 18. Data UI CQRS W R C Q
- 19. Data UI CQRS Data W R C Q
- 20. Data E UI CQRS Data W R C Q
- 21. Data UI CQRS Data E W R C Q
- 22. Event Source W UI CQRS R C Q Data E E
- 23. Why? Scalability Flexibility Reduced complexity Focus on business Task based UI
- 24. CQS was first on the scene
- 25. What is CQS? • CQS: Command Query Separation • Command methods change state • Query methods read state • One object in code for state change and querying works • Using the same data store is ok • Supports shared schema with read replica concepts
- 26. CQS in code: NOT public class User { public string Address { get; set; } }
- 27. CQS in code: BETTER public class Entity { //... public void Move(string newAddress) { //changes state } public string GetAddress() { //queries state } }
- 29. DDD: At a high level • CQRS is based on DDD • DDD is used to address complexity • Aggregate Roots • Bounded Contexts • Domain Events
- 30. DDD: Ubiquitous Language • Domain experts • Technical team • Shared language • Model based on the shared language
- 31. DDD: Entities • Have identity • Items like • User • Product • Order
- 32. DDD: Value Objects • Have value, no identity • Items like • User.Address • Product.TechNotes • Order.OrderItem
- 33. DDD: Aggregates and their Root • An aggregate of one or more Entities and Value objects • One Entity is the Root that is used to reference the aggregate • Conceptual boundary by root • Consistency boundary • transactional Order OrderHeader OrderItem
- 34. DDD: Bounded Context • Two or more distinct (obviously related) models • Interactions between them • Usually delineated by business groups or tasks HotelBookings Order OrderHeader OrderItem Availability Property Reservation Payment Processor HotelMarketing Content Campaign Property
- 35. DDD: Domain Event • Represents something that happened in the past • Immutable • Historical record Would like to do... Am doing... Is done. PlaceOrder Command PlaceOrder Handler OrderPlaced Event
- 37. DDD: Visualized Application Bounded Context
- 38. DDD: Visualized Application Bounded Context Business Component
- 39. DDD: Visualized Application Bounded Context Business Component Autonomous Business Component
- 40. Back to CQRS
- 41. What is CQRS? • CQRS: Command & Query Responsibility Segregation “Two objects where there once was one” • Command objects change state • Query objects read state • Two objects represented in code • One for state change • One for querying data • Decoupled model for different concerns
- 42. CQRS in code public class UserWriteService { // Commands public void Move(User user, string newAddress); //... } public class UserReadService { // Queries public User GetUser(int userId); //... }
- 43. Segregation opens doors • Scale reads from writes independently • Remove contention • Decouple read model from write model • Different data shapes • Flexibility in modeling different concerns • Ability to capture with why the state changed • Not just changing the state
- 44. CQRS: Command • Message • Handler changes state • Always returns void (nothing) • Works with business intent, not just a record • Not a CRUD style operation
- 45. CQRS: Command in code public class MoveCustomerCommand : Command { public Address NewAddress { get; set; } }
- 46. CQRS: Query • Does not change state • Has return value • Also a type of message
- 47. CQS vs. CQRS: Feature matrix CQS CQRS Zero coupling between domain logic (state) and reporting (read) concerns X More robust scalability options X Decouples domain concerns from display concerns X Object model specific to its responsibility X Different data stores/shapes for domain logic and reporting concerns X Option to performance optimize data storage for write and read layer(s) X X Can be used with a message based architecture X X Easy deployment story X Less code complexity X Less pieces to manage X Coupled read and write model X
- 48. Let’s take a closer look!
- 49. What does CQS look like? • Data shape IS the same • Client creates data through one set of methods • Client reads data through another set of methods • Likely the same object model • The read and write model are likely the same • Or a sub-set thereof • Can support read replicas (at DB) • Doesn’t support multiple different containers of data Data Store Data Store Server Client Read Operations Write Operations
- 50. What does CQRS look like at a high level? Data Store Query Model Command Model Service Potential for composite views Application routes change information Client Command model executes validations, and consequential logic Can be same store or different store, but is guaranteed to be different schema and different data shape Opportunity for message oriented architecture • Store can be the same • Data shape IS different • Data flow is different • Zero model concerns are leaked to view concerns
- 51. CQRS: Myth busting • CQRS requires Event Sourcing • Requires an eventual consistent read store • Requires a bus/queues/asynchronous messaging • Commands are fire and forget • Escapes consistency problems and eliminate concurrency violations • CQRS is easy!
- 52. What does CQRS look like for us? Warehouse Denormalizer View 2 Denormalizers can read from “rich domain mo del” to “enrich” message in hand. Denormalizer Data Warehouse Read Store Service Service Queue Store Client API/Web Server NSB Saga Store Service Source of Truth Read Store API/Web Server Rich Domain Read/Write Model Queue Store NSB View 1 Denormalizer View 2 Denormalizer NSB Two camps 1) One table per view 2) Composite view Can be same code base, can be deployed separately and segregated at the action level with routing foo Potential to support read replicas • Store for each • Rich domain • View concerns • Reporting concerns • Data shape IS different • Messaging for distribution • Lots of scalability options • Supports different storage mechanisms
- 53. Anything else about CQRS? • UI workflow might be different • Synchronous UI flow: view form > submit > confirmation page • Asynchronous UI flow: view form > submit > processing > email confirmation • Not every avenue through your code has to be CQRS! • Sometimes there business needs that might like a more direct route • Move work out of process only when needed, distributed is harder • This can be done with an in memory bus
- 54. Worth reading • Microsoft: CQRS Journey • Jimmy Bogard: Busting some CQRS myths
- 55. Any questions? Code and slides: https://github.com/asiemer/IntroToCQRS andrew@clear-measure.com @asiemer
Notas do Editor
- Introduction to CQRS Break down the acronym: command and query responsibility segregation
- Andrew Siemer, obstacle races, ranching, shooting, ASP Insider, Microsoft Virtual Technology Solution Professional
- Some books I have written or am writing, heavy focus on asp.net and web programming
- Some places I have worked and some projects I have worked in the past. ClearMeasure is always hiring the best! Become a part of our family.
- Mention Greg Young’s concept of “CQRS is simply the creation of two objects where there was previously only one”
- Break down what exactly does CQRS mean in three sentences or less.
- Introduction – We will take a look at what CQRS is, what it isn’t, how it came to be, and where it fits. This talk will get you up to speed well enough that you can think about CQRS, but implementing CQRS means something different to everyone. You should be able to pick and choose which ideas that tend to surround CQRS are right for you. But you will likely need more study to implement this idea correctly.
- Framework – While there are frameworks you can get to make implementing a given notion about CQRS quicker, it is not a framework Architecture – Think about CQRS being something you can do as a piece of your overall architecture Tool – And while there are tools to help you implement pieces of CQRS it is not a tool Best – CQRS if far from the best thing for most projects and we will see why
- A best practice is an approach to be used to solve a specific problem. CQRS can cause you more problems that it can solve pretty quickly once you start down this rabbit hole. Be cautious.
- Coined by Bertrand Meyer Command returns nothing Query has return value Query does not change state Command does change state
- Domain Driven Design was to some a revelation in how we structure our applications. But once distrusted became a mainstream concept DDDD started to show up where the fourth D is distributed. CQS became popular but still semi-dirty with models being mixed for reads and writes. Once it was seen that the responsibility of reads and writes needed to change…we were off. Decoupling the two concerns yields more flexibility.
- Traditional multi-tier app, all reads and writes goes through the same plumbing
- Separation between reads and writes, but same middle layer
- Separation at a code for reads vs writes
- The ability to separate the database for reads and writes
- We can add events and support read layers for different purposes
- Async eventing becomes easier too!
- With this model you can then also move to event sourcing
- With this model you can then also move to event sourcing
- Changing the state of the user’s address loses all intent as to why the change was made Was the address changed due to a typo, did they move, did they get married No separation between state change and queries – forced coupling of model Can’t scale any of this independently
- This is allows you separate how you read and write. Which is better. But you lose the intent. Why did this entity move?
- Essential part of DDD Breaks business concerns into appropriately sized buckets Principles: Intention-revealing Side-effect free functions Clear encapsulation
- A single language that all involved parties can use to talk about the business.
- Used to describe the important things in your model as it pertains to a given business area.
- The important, albeit less important, things that dangle from your Entities. The meta data used to describe an entity in full.
- Used as the primary point of interaction with a set of entities that are closely related. A consistency boundary Has identity, rather than value. Introduction of Entity/Value type just to describe aggregates
- As you model out a business area you might quickly find that a “Product” to one part of your business is not the “Product” that another business area describes. It is entirely acceptable to have multiple representations of similar items that exist in your business language. They may share an ID across boundaries (a correlation ID)…but their state is likely stored separately.
- Hotel management application
- An application can have many bounded contexts Hotel management might have Property management: what rooms are available Content management: what are the various room amenities Deal management: what rooms would we like to get filled
- A bounded context can have many business components Within property management we may need to answer questions like What rooms are available with 2 queen beds Smoking or non-smoking rooms available Handicap accessible UI to database in a business component
- A business component can have many separately deployable autonomous business components An end point that serves data An end point that servces UI A service that processes commands and events
- The topic of CQRS really is about what possibilities this segregation offers. Reduces accidental restrictions through the promotion of explicitness and separation of concerns.
- What we’ve seen so far are implicit commands. CQRS uses the well-known Command Message Pattern. Makes *intent of change* explicit Not just a ChangeRecordCommand A “correct address” task—which technically identical—is separate from a “move” task
- The opposite of a Command is query Gets state, does not change state.
- Event Sourcing has nothing to do with CQRS…but they do play well together Eventual consistency is not required by CQRS –that is a side effect of a truly distributed non-RPC style application You can make a synchronous CQRS system where a command is fired and you wait for all work to be completed A bus, messaging, etc. is not required by CQRS. But CQRS is modeled in such a way that slipping in messaging and a bus fits nicely Do be aware that anything eventually consistent adds to the complexity of what you need to handle on your side Anything that will eventually be worked on means that they could fail in an unexpected way. If your user has already moved on, you need to handle success/fail scenarios. You must plan down to the most minute detail to ensure that all scenarios are handled. Network unplugged? Message delivered more than once? Price updated – data not replicated? As with any added widgets to track and handle – complexity goes up. Number of widgets to build is greater. Test area grows. Deployment complexity increases.