introduction to cqrs
Post on 14-May-2015
1.709 Views
Preview:
TRANSCRIPT
INTRODUCTION
CQRS
PIETER JOOST VAN DE SANDE
THANK YOU VSOFT!!
AGENDA• How we do things now
• What CQRS changes to that
• Building a CQRS architecture
• Some demo stuff
• Discussion
• Beer!
TYPICALARCHITECTURES
YOU SHOULD RECOGNIZE THIS
TYPICAL ARCHITECTURES
TYPICAL ARCHITECTURES
Presentation
Domain
Data
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.
• Supported by tools and frameworks
• Lots of resources available
WHAT THE N-TIER TUNNEL BROUGHT US
TYPICAL ARCHITECTURES
TWO FUNDAMENTAL THINGS
EVERY SYSTEM HAS THIS
DATA
TRANSITIONS
WHAT IS CQRS?
COMMAND
QUERY
RESPONSIBILITY
SEGREGATION
CQRS CONCEPT
MOVE FROM N-LAYER TO…
N-LAYERARCHITECTURE
Presentation
Domain
Data
Presentation
Domain
Data
Presentation
DomainData
Presentation
DomainData
Read State transitions
Presentation
DomainData
FROMCQRS CONCEPTTOARCHITECTURE
THIS ADDS MORE VALUE!
User interface
DEMAND FOR DATA
BECAUSE WE HAVE SOME SCREENS TO FILL
WE READ A LOT
WE HAVE MULTIPLE SCREENS TO FILL
DATA SHOULD BE CLOSE TO US
DEMAND FOR DATA• User interface has different views to fill.
• It should not have to execute business rules on the data.
• It requests data many times.
• It should be close to us.
• Getting data should be simple (select * from x where y)
Examples:
• Get all products of user X• Get total price of all orders of month May
User interface
User interface
Read side
Read side
User interface
Read databases
Read side
User interface
Read databases
query
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
Read side
User interface
Read databases
query
DEMAND FOR CHANGE
OTHERWISE THINGS ARE STATIC
I WANT TO TELL THE SYSTEM SOMETHING
Please move customer X to this new address
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 addressVS.
MULTIPLE STEPS
Users can take multiple steps before they reach the end goal. These steps can be very useful to us.
Create Cart Add item Add item Add item Remove
item Purchase
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
Read side
User interface
Read databases
query
Write side Read side
User interface
Read databases
query
Commandhandlers
commands
Write side Read side
User interface
Read databases
query
User interface
Commandhandlers
Read databases
Read side
commands DTO’s
Dom
ain
Write side
Facade
GREG YOUNG:
“State transitions are an important part of our problem space and should be modeled within our domain.”
THE ‘OLD’ DOMAIN MODEL
DOMAIN FOCUSED ON BEHAVIOR
User interface
Commandhandlers
Read databases
Read side
commands DTO’s
Dom
ain
Write side
Facade
User interface
Commandhandlers
Read databases
Read side
commands DTO’s
Dom
ain
Write side
Repository
Facade
User interface
Commandhandlers
Read databases
Read side
commands DTO’s
Dom
ain
Write side
Repository
Facade
?
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
EVENTUAL CONSISTENCY• Updates will eventually propagate through the system.
• This means we need to think differently about concurrency!
User interface
Commandhandlers
RepositoryRead databases
Write side Read side
eventscommands DTO’s
Dom
ain
Facade
User interface
Commandhandlers
Repository
Den
orm
alize
rs
Read databases
Write side Read side
eventscommands DTO’s
Dom
ain
Facade
DENORMALIZERS
• Will keep the read models up to date based on the event stream.
• An event can cause multiple updates.
User interface
Commandhandlers
Repository
Event bus
Den
orm
alize
rs
Read databases
Write side Read side
events
events events
commands DTO’s
Dom
ain
Facade
EVENT SOURCING
User interface
Commandhandlers
Repository
Event bus
Den
orm
alize
rs
Read databases
Write side Read side
events
events events
commands DTO’s
Dom
ain
Facade
events
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
FINAL FLOW
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
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
NCQRS
THE CQRS FRAMEWORK FOR .NET
THANK YOU!YOU’VE BEEN A GREAT AUDIENCE!
top related