cqrs andriy drozdyuk
TRANSCRIPT
this slide left intentionally blank
CommandQueryResponsibilitySegregation
Andriy Drozdyuk
Outline
1. Stereotypical Architecture2. Why SA is used3. Task Based UI4. CQRS5. Query Side6. Command Side
Stereotypical Architecture
Why?
Simple
1. Any junior developer can be taught it2. Very generic3. Widely known4. Removes the need to think about architecture
Tooling
1. Frameworks2. ORM3. Mapping utilities
Why Not?
Downsides
1. Impossible to do Domain Driven Design
Data Oriented
Data Oriented
Same
Data Oriented
Same
Create Read
Update Delete
Data Oriented
Same
Create Read
Update Delete
Anemic Domain Model(Martin Fowler)
Anemic Domain Model
[T]here is hardly any behavior on these objects, making them little more than bags of getters and setters. … Instead there are a set of service objects which capture all the domain logic. These services live on top of the domain model and use the domain model for data. (Martin Fowler, 2003)
DO DTO
DO DTO
Get, Set
DO DTO
Get, Set
Business Logic?
DO DTO
Get, Set
Business Logic?Mappers
DO DTO
Get, Set
Business Logic
Business Logic?Mappers
This is far worse than the creation of an anemic model, this is the creation of a glorified excel spreadsheet.-Greg Young
Scaling Characteristics
1. Bottlenecksa. Data storageb. Relational Databases: not horizontal, vertical expensive
2. Most systems don’t need to scale
Task Based UI
Stereotypical Architecture UI
1. Loses “intent” of the user2. Data centric DTOs3. Domain without verbs4. Behavior lives in the client
Behavioral Interface
1. Bring intention of the user forward
Commands
1. Command = operation name + data required2. Imperative tone3. Only carry necessary information
Operation name + data required
class ReserveSeatCmd(flightId:GUID, seat:Int)
Imperative tone
MakeSaleCommand
vs:
SaleOccured
Only required information
MakeSaleCommand(date:Date, amount:Price)
vs.
class SaleDTO { date: Date amount: Price, cleared: Bool, isDeleted: False, preferred: False}
Good or Bad?
ChangeAddress
Good or Bad?
ChangeAddress
Try “Correct Address”, “Relocate Customer”
Good or Bad?
CreateUser
Good or Bad?
CreateUser
Try “RegisterUser”
Good or Bad?
DeleteCourse
Good or Bad?
DeleteCourse
Try “UnenrollStudent”
Commands
1. Not difficult but unfamiliar2. Seen as a lot of work3. If bottleneck, likely doing it in the wrong place
CQRS
Split model in two
1. One containing Queries2. One containing Commands
Command Query
1. Consistency Consistent Eventual
2. Data Storage 3NF 1NF
3. Scalability Few transactions Many requests
It is not possible to create an optimal solution for searching, reporting, and processing transactions utilizing a single model
-Greg Young
Query Side
Problems with queries in SA
1. Projected from Domain2. DTO should match UI3. Domain Models should match business
Common Smells
1. Repositories with read methods (paging, sorting)2. Getters on Domain Objects3. Prefetching4. Loading multiple aggregates5. Optimizing queries is hard
Common Smells
1. Repositories with read methods (paging, sorting)2. Getters on Domain Objects3. Prefetching4. Loading multiple aggregates5. Optimizing queries is hard
Impedance Mismatch
Benefits
1. Does not suffer from impedance mismatch2. Queries can be optimized, fine-tuned3. Developers only have to understand data model4. Developers don’t need to know ORM5. Domain not affected by query requirements & can be specialized
Command Side
Problems with SA
1. Domain handled both commands and queries2. Caused issues with the Domain
Common Smells
1. Repositories with many read methods (paging, sorting)2. Getters on Domain Objects3. Prefetching4. Loading multiple aggregates
Benefits
1. Domain focused on processing commands2. Domain Objects no longer expose state3. Repositories with few query methods (i.e. getById)4. Aggregate boundaries
Separate Models Costs & Benefits
1. Relatively easy to separate Queries and Commands2. Lowers cost of optimization (querying)3. Domain model - less conceptual overhead4. Worst case: Cost(CQRS) = Cost(SA)
a. Occurs when Query Side uses domain underneath
Can go further...
Look at
1. Domain Events2. Event Sourcing3. Actors
References
1. CQRS Documents by Greg Younghttps://cqrs.wordpress.com/documents/
2. Eric Evans, Domain-Driven Design, 2004.3. Fighting bottlenecks with CQRS
http://verraes.net/2013/12/fighting-bottlenecks-with-cqrs/4. Microsoft CQRS
https://www.microsoftpressstore.com/articles/article.aspx?p=22488095. CQRS Pocket Guide
http://cqrs.wikidot.com/
The End
this slide left intentionally blank
Extra Slides
Data Oriented
Same
Data Oriented
Same
Create Read
Update Delete
Data Oriented
Same
Create Read
Update Delete
Anemic Domain Model(Martin Fowler)
Data Oriented
Prototypical Architecture
CQRS Architecture
DTOsCommands
Events
State &
Invariants
Task Based
UI
DO - DTOs
DO - DTOs
Get, Set
DO - DTOs
Get, Set
Business Logic?
DO - DTOs
Get, Set
Business Logic?Mappers
DO - DTOs
Get, Set
Business Logic?Mappers
Business Logic