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

What CQRS is NOT

DDD revisited

Usual Patterns

▫ Entities

▫ Value Objects

▫ Repositories

DDD revisited

Some Important Patterns

▫ Ubiquitous Language

▫ Bounded Contexts

▫ Core Domain

▫ Domain Experts

DDD Revisited

An Example: Competitive advantage through an efficient online claims procedure

DDD revisited

DO use DDD:

▫ Where we get competitive advantage

DDD revisited

DO use DDD:

▫ Where we get competitive advantage

DON‘T use DDD

▫ When there‘s no value in formalizing the problem

DDD revisited

• The point of DDD is not Software Analysis

DDD revisited

• The point of DDD is not Software Analysis

• It‘s Business Analysis

„Best-Practice“ Architecture

„Best-Practice“ Architecture

„Best-Practice“ Architecture

• Pros:

▫ Easy to build

▫ Accepted by management

▫ Well known

„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?

Domain Model Responsibilities

• Business Logic • Validation • Structure • Associations • Scopes, Filters • Aggregation • Presentation • Persistence • Lazy / Eager Loading • …

The S in SOLID

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

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.

CQS on an Architectural Level

Data Storage

Commands Queries

Project List

Project Details

Project

Basic CQRS Architecture

Data Storage

Thin Read Layer ORM

Domain Model

Command Handlers

Client

Commands Queries

The Parts: Thin Read Layer

• Concerns:

▫ Filtering, Scope

▫ Data Presentation

• Attributes

▫ Data-Oriented

▫ Indexable

▫ Can be Denormalized for fast access

▫ Only Structure

The Parts: Domain Model

• Concerns: ▫ Validation ▫ Business Logic

• Attributes: ▫ Normalized ▫ Object Oriented ▫ Transactional ▫ Persistence Ignorant ▫ Only Behaviour

The Parts: Task-Based UI

The Parts: Task-Based UI

The Parts: Task-Based UI

The Parts: Commands

Refactoring: Application Service Calls to Objects

Commands:

▫ Are Serializable

▫ Can be enveloped

▫ Can be intercepted

▫ Can be enriched

▫ Communicate intent

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

This is CQRS! Complicated?

Data Storage

Thin Read Layer ORM

Domain Model

Command Handlers

Client

Commands Queries

But what about Eventual Consistency?

Source: www.kinoweb.de

The First Rule

CQRS can be perfectly consistent!

Data Storage

Thin Read Layer ORM

Domain Model

Command Handlers

Client

Commands Queries

Advanced topics for another day

• Events

• Sagas

• Event Log

• Messaging

• Service Busses

• NoSQL

• Event Store

Thanks!

Dennis Traub @DTraub

Resources

• cqrsinfo.com

• groups.google.com/group/dddcqrs

• distributedpodcast.com