14. „Best-Practice“ Architecture
• Cons:
▫ Limited scalability
▫ Loss of intent
▫ Lazy Loading
▫ Data Projection
▫ Pain
▫ And: If Domain is only CRUD, where does
Business Logic live?
18. Read vs. Write
• Reads and Writes are completely different from
eachother
• Why do we try to build the One Model to
Rule Them All?
• Sometimes it‘s cheaper to do two things than
dealing with the trade-offs
19. Command-Query Separation
• Bertrand Meyer:
▫ Every method should either be a command that
performs an action, or a query that returns data
to the caller
• In other words:
▫ Asking a question should not change the answer.
20. CQS on an Architectural Level
Queries Commands
Project Project Project
Details List
Data Storage
21. Basic CQRS Architecture
Data Storage
ORM Thin Read Layer
Domain Model
Command Handlers
Commands Queries
Client
22. The Parts: Thin Read Layer
• Concerns:
▫ Filtering, Scope
▫ Data Presentation
• Attributes
▫ Data-Oriented
▫ Indexable
▫ Can be Denormalized for fast access
▫ Only Structure
23. The Parts: Domain Model
• Concerns:
▫ Validation
▫ Business Logic
• Attributes:
▫ Normalized
▫ Object Oriented
▫ Transactional
▫ Persistence Ignorant
▫ Only Behaviour
27. The Parts: Commands
Refactoring:
Application Service Calls to Objects
Commands:
▫ Are Serializable
▫ Can be enveloped
▫ Can be intercepted
▫ Can be enriched
▫ Communicate intent
28. The Parts: Command Handlers
Refactoring:
Application Service to Command Handler
Command Handlers:
▫ Unify interface to all application services
▫ Can be wrapped (e.g. Transaction, Authorization,
Logging, etc.)
▫ Can be enveloped (e.g. RESTful Envelope)
▫ Rule of Thumb: One Command Handler per Use Case
29. This is CQRS! Complicated?
Data Storage
ORM Thin Read Layer
Domain Model
Command Handlers
Commands Queries
Client