1) CQRS is an architectural pattern that separates read and write operations into different models. This allows for optimized read and write models and behaviors. 2) The basic CQRS architecture involves separating the read and write concerns into different layers - a thin read layer for optimized querying and presentation, a domain model for business logic and validation, and command handlers that process commands to enact changes. 3) CQRS does not require eventual consistency - the read and write models can be kept perfectly consistent through mechanisms like event sourcing that propagate write events to the read models.

1. CQRS – Eine Einführung
.Net Online Usergroup – 10.10.2011
Presenter: Dennis Traub
Speaker, Author, Software Developer since 1991
Currently at ProAvia GmbH, Stuttgart
Twitter: @DTraub

2. What CQRS is NOT

4. DDD revisited
Usual Patterns
▫ Entities
▫ Value Objects
▫ Repositories

5. DDD revisited
Some Important Patterns
▫ Ubiquitous Language
▫ Bounded Contexts
▫ Core Domain
▫ Domain Experts

6. DDD Revisited
An Example:
Competitive advantage through an efficient
online claims procedure

7. DDD revisited
DO use DDD:
▫ Where we get competitive advantage

8. DDD revisited
DO use DDD:
▫ Where we get competitive advantage
DON‘T use DDD
▫ When there‘s no value in formalizing the problem

9. DDD revisited
• The point of DDD is not Software Analysis

10. DDD revisited
• The point of DDD is not Software Analysis
• It‘s Business Analysis

11. „Best-Practice“ Architecture

12. „Best-Practice“ Architecture

13. „Best-Practice“ Architecture
• Pros:
▫ Easy to build
▫ Accepted by management
▫ Well known

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?

15. Domain Model Responsibilities
• Business Logic
• Validation
• Structure
• Associations
• Scopes, Filters
• Aggregation
• Presentation
• Persistence
• Lazy / Eager Loading
• …

16. The S in SOLID

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

24. The Parts: Task-Based UI

25. The Parts: Task-Based UI

26. The Parts: Task-Based UI

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

30. But what about Eventual Consistency?

31. The First Rule
Source: www.kinoweb.de

32. CQRS can be perfectly consistent!
Data Storage
ORM Thin Read Layer
Domain Model
Command Handlers
Commands Queries
Client

33. Advanced topics for another day
• Events
• Sagas
• Event Log
• Messaging
• Service Busses
• NoSQL
• Event Store

34. Thanks!
Dennis Traub
@DTraub

35. Resources
• cqrsinfo.com
• groups.google.com/group/dddcqrs
• distributedpodcast.com