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