Éric De CarufelHOW DDD, CQRS AND

EVENT SOURCING CONSTITUTE THE

ARCHITECTURE OF THE FUTURE

© P

yxis

Tec

hnol

ogie

s in

c.

BEFORE TALKING ABOUT THE FUTURE LET'S TALK ABOUT THE

PAST

© P

yxis

Tec

hnol

ogie

s in

c.

1960 - BATCH PROCESSING / MAINFRAME

© P

yxis

Tec

hnol

ogie

s in

c.

1970 - ONLINE TRANSACTION PROCESSING (OLTP) / SABRE

© P

yxis

Tec

hnol

ogie

s in

c.

1980 - DESKTOP PC / LAN

© P

yxis

Tec

hnol

ogie

s in

c.

1990 - 3 TIERS / SERVER / INTERNET

© P

yxis

Tec

hnol

ogie

s in

c.

2000 - SOA / WEB / WEB SERVICES

© P

yxis

Tec

hnol

ogie

s in

c.

2010 - WEB 2.0 / MOBILE / REST

© P

yxis

Tec

hnol

ogie

s in

c.

ARCHITECTURE MUST COMMUNICATE MAJOR

IMMUTABLE DESIGN DECISION VIA UNDERSTANDABLE

ABSTRACTIONS

© P

yxis

Tec

hnol

ogie

s in

c.

11

MONOLITHIC APPLICATION

Database

Business logic

User interface

© P

yxis

Tec

hnol

ogie

s in

c.

12

Database

Business logic

CLIENT/SERVER APPLICATION

User interface

Database

Business logic

User interface

© P

yxis

Tec

hnol

ogie

s in

c.

13

User interface

Database

Business logic

N-TIER APPLICATION

User interface

Database

Business logic

Database

Business logic

User interface

© P

yxis

Tec

hnol

ogie

s in

c.

14

User interface

Database

Business logic

TYPICAL ARCHITECTURE

User interface

Database

Business Logic

Database

Business logic

User interface

© P

yxis

Tec

hnol

ogie

s in

c.

Each layer depends on another layerUsually all layers depends on the same infrastructure

layerUI is tightly coupled with the database (read and write)

Data layer objects often leak all the to UIData structure has big side effect on domain and UISingle point of failure (the single database)

After some time, system like that are too hard to maintain and they become legacy and get rewritten (Usually using the same architecture)

WHAT'S WRONG WITH LAYERED ARCHITECTURE

© P

yxis

Tec

hnol

ogie

s in

c.

SIMPLE DATA MODEL

© P

yxis

Tec

hnol

ogie

s in

c.

ADDING NEW FEATURES

© P

yxis

Tec

hnol

ogie

s in

c.

Doesn't easily allow Domain Driven Design (DDD) concept

Usually works with CRUDThis reflect to the UI when a user must know the

data structure to make changesThe system doesn't capture user intentionHow to implement…

Auditing / Logging / Traceability?Reporting?Distributed data?

DATA DRIVEN ARCHITECTURE

© P

yxis

Tec

hnol

ogie

s in

c.

COMPLETED PRODUCT

© P

yxis

Tec

hnol

ogie

s in

c.

EVOLUTION…?

EACH CHANGE TAKE EXPONENTIALLY

MORE TIME THAN THE PREVIOUS

© P

yxis

Tec

hnol

ogie

s in

c.

CAP THEOREM IN DISTRIBUTED SYSTEM

Availability

PartitioningConsistency

A

C P

CA AP

CP

SQL ServerOracle

MongoDBRedis

CassandraCouchDB

CAN'T HAVE ALL 3 AT THE SAME TIME

© P

yxis

Tec

hnol

ogie

s in

c.

22

UI DataBusiness

Request

Command Write

Read

TYPICAL APPLICATION

OPTIMIZE READ WITH INDEXES

INDEXES AS NEGATIVE PERFORMANCE ON WRITES

CAN'T OPTIMIZE READ AND

WRITE ON THE SAME DATABASE

© P

yxis

Tec

hnol

ogie

s in

c.

23

UI DataBusiness

Request

Command Write

Read

WORKING WITH STALE DATA

20ms 100ms

20ms 100ms

100ms

20ms

Approx. 360ms. + User thinking

1000+ ms.

DATA ARE ALWAYS STALE

© P

yxis

Tec

hnol

ogie

s in

c.

HOW TO BUILD PERFORMANT (DISTRIBUTED) SYSTEM THAT

TAKE ACCOUNT STALE DATA AND IS EASY TO MAINTAIN AND

EVOLVE?

© P

yxis

Tec

hnol

ogie

s in

c.

Domain ObjectsEntityValue objectAggregate (root)

InfrastructureServiceRepositoryFactory

DDD TERMINOLOGY

© P

yxis

Tec

hnol

ogie

s in

c.

AN ENTITY IS NOT DEFINED BY ITS ATTRIBUTES. IT IS ONLY IDENTIFIYABLE BY A

UNIQUE IDENTITFIER. IT CAN EVOLVE THROUGH TIME AND CAN BE ASSOCIATED

WITH OTHER OBJECTS

ENTITY

© P

yxis

Tec

hnol

ogie

s in

c.

A VALUE OBJECT IS DEFINED BAY ALL ITS ATTRIBUTES. IT CAN BE PASS ONLY BY

IMMUTABLE COPY OF ITSELF. ANY CHANGE WOULD RESULT IN A NEW AND UNRELATED

OBJECT.

CONTEXT MATTER!

VALUE OBJECT

© P

yxis

Tec

hnol

ogie

s in

c.

AN AGGREGATE IS A CLUSTER OF ENTITY AND VALUE OBJECT THAT ARE CLOSELY

RELATED.

(ONE ENTITY IN THAT CLUSTER ACT AS A ROOT OBJECT AND IS THE ONLY ONE THAT CAN BE REFERENCED FROM THE OUTSIDE)

AGGREGATE (ROOT)

© P

yxis

Tec

hnol

ogie

s in

c.

SERVICE IS A STATELESS OBJECT THAT USE DOMAIN OBJECT AS INPUT AND OUTPUT.

SERVICE OPERATION SHOULD NOT BE SOMETHING THAT BELONG TO ENTITY OR

VALUE OBJECT.

SERVICE

© P

yxis

Tec

hnol

ogie

s in

c.

A (DOMAIN) REPOSITORY ACT AS AN ABSTRACTION BETWEEN AN AGGREGATE AND ITS PERSISTENCE. IT TAKE CARE OF

RECREATING AN INSTANCE FROM ONE OR MANY PERSISTENCE SOURCES.

REPOSITORY

© P

yxis

Tec

hnol

ogie

s in

c.

A FACTORY ONLY CREATE OBJECT IN A CONSISTENT STATE WITH ALL INVARIANTS

SATISFIED. THIS CONSTRUCTION SHOULD BE AN ATOMIC PROCESS.

FACTORY

© P

yxis

Tec

hnol

ogie

s in

c.

32

SEPARATE READ FROM WRITE

UI Write model

DomainCommand Write

Commands - change data

UI Read model

QueryRequest Read

Queries - read data (no side effect)

© P

yxis

Tec

hnol

ogie

s in

c.

33

WE NEED TO SYNCHRONIZE WRITE AND READ MODELS

UI Write model

DomainCommand Write

Commands - change data

UI Read model

QueryRequest Read

Queries - read data (no side effect)

© P

yxis

Tec

hnol

ogie

s in

c.

DEFINE SOMETHING THAT HAPPENED IN THE PASS. IT IS IMMUTABLE. IT

MUTATE THE STATE OF AN AGGREGATE AND KEEP IT COHERENT.

IT IS SEQUENTIAL AND SERIALIZABLE.

DOMAIN EVENT

© P

yxis

Tec

hnol

ogie

s in

c.

Invite the right people People that know the questions People that know the answers

Provide unlimited modeling spaceExplore and define Domain Events

Relevant to business Placed in order

Explore origin of Domain Events User action are commands Time may trigger some events

Group events in aggregates Derive entities and value objects

EVENT STORMING

© P

yxis

Tec

hnol

ogie

s in

c.

EVENT SOURCING

AGGREGATE

OrderCreated

ProductAdded

ProductAdded

ProductRemove

dProductAdded

OrderComplet

ed

AN AGGREGATE HOLDS HIS OWN DOMAIN EVENTS AND BUILD ITS STATE FROM THEM

© P

yxis

Tec

hnol

ogie

s in

c.

MANY PERSPECTIVES ON DATA

Customer

Product

CostMarkup

Quantity

PriceQuantity OrderedName

Buyers InventoryManager

SalesRep.

© P

yxis

Tec

hnol

ogie

s in

c.

MANY PERSPECTIVES ON DATA

Buyers InventoryManager

Product

Quantity

ProductId

Product

CostMakup

ProductId

Product

PriceQuantity OrderedName

ProductId

Shared Entity Identity

SalesRep.

Bounded Context

© P

yxis

Tec

hnol

ogie

s in

c.

PUTTING IT ALL TOGETHER

Client

Commands CommandBus

Sends

Command Handlers

Modify

Repositories

Read Write

Datastore

EventBus

Publish Events

EventBus

Command Services

Event HandlersEvents

Denormalized

Read storeQuery

Facade

Query HandlersQuery Results

Queries

Query Services

Events

Domain

UI

adaptation from Jeppe Cramon

© P

yxis

Tec

hnol

ogie

s in

c.

DO NOT DESIGN FOR LOCALITY AND TRY TO DISTRIBUTE

DESIGN FOR DISTRIBUTION, TAKE ADVANTAGE OF LOCALITY

© P

yxis

Tec

hnol

ogie

s in

c.

DO START WITH SYNCHRONOUS CALLS AND TRY TO MAKE THEM

ASYNCHRONOUS

START WITH ASYNCHRONOUS CALLS AND SYNCHRONIZE THE RESPONSES

QUESTIONS