Jak Charltonjak@thinkddd.comwww.thinkddd.com

Readify www.readify.net

Practical Domain Driven Design

Practical Domain Driven Design

Message Based Architecture and CQRSMessage Based Architecture and CQRS

Domain Driven Design ISDomain Driven Design IS

An architectural methodology

for evolving a software system

that closely aligns to business requirements

An architectural methodology

for evolving a software system

that closely aligns to business requirements

Domain Driven Design IS NOT

Domain Driven Design IS NOT

A silver bulletA panacea for all your troublesAn easy path to followAlways the best solution

And most importantly, it is not focused on the How, but the What and Why

A silver bulletA panacea for all your troublesAn easy path to followAlways the best solution

And most importantly, it is not focused on the How, but the What and Why

Where Are We Going?Where Are We Going?

The Domain Vision Statement

The Domain Vision Statement

A shared understanding of what it is you are actually trying to create

Should be brief, written in clear English and understood by business and tech people alike

Should be factual, realistic, honest Should avoid superlatives and

marketing speak Should avoid technical and

implementation details

A shared understanding of what it is you are actually trying to create

Should be brief, written in clear English and understood by business and tech people alike

Should be factual, realistic, honest Should avoid superlatives and

marketing speak Should avoid technical and

implementation details

Domain = Sphere of Activity?

Domain = Sphere of Activity?

DomainDomain

A Domain is a Sphere of Knowledge, Influence or Activity

A Domain is represented by the Ubiquitous Language

A Domain encapsulates a Domain Model

A Domain lives within a Bounded Context

A Domain is a Sphere of Knowledge, Influence or Activity

A Domain is represented by the Ubiquitous Language

A Domain encapsulates a Domain Model

A Domain lives within a Bounded Context

The Ubiquitous LanguageThe Ubiquitous Language

Human languages are Lossy Abstractions

A major reason for failure of software projects is a failure of people, the failure to communicate

The Ubiquitous Language is a shared language between the business and the development teams

The UL comes from the business, and is enriched by the development teams

Human languages are Lossy Abstractions

A major reason for failure of software projects is a failure of people, the failure to communicate

The Ubiquitous Language is a shared language between the business and the development teams

The UL comes from the business, and is enriched by the development teams

Domain ExpertsDomain Experts

Domain Experts are the primary point of contact the development teams have with the business

They are the Experts on their part of the business, not just users of the system

They should have deep knowledge of the subject Domain

Domain Experts are the primary point of contact the development teams have with the business

They are the Experts on their part of the business, not just users of the system

They should have deep knowledge of the subject Domain

Looks Pretty Unique To MeLooks Pretty Unique To Me

EntitiesEntities

Entities are the “things” within your Model

An Entity is defined by being unique, and uniquely identifiable

Entities have behaviour

Entities are the “things” within your Model

An Entity is defined by being unique, and uniquely identifiable

Entities have behaviour

You Can’t Tell One From Another

You Can’t Tell One From Another

Value ObjectsValue Objects

Value Objects are the “things” within your model that have no uniqueness

They are equal in all ways to another Value Object if all their properties match

Value Objects are interchangeable

Value Objects are the “things” within your model that have no uniqueness

They are equal in all ways to another Value Object if all their properties match

Value Objects are interchangeable

How Can We Make Sense?

Domain ModelDomain Model

A Domain Model is a representation of the relationships between the Entities and Value Objects in your Domain

It may look similar to UML or a class relationship diagram, but it is not one

The Domain Model should be recognisable and understandable by the business

A Domain Model is a representation of the relationships between the Entities and Value Objects in your Domain

It may look similar to UML or a class relationship diagram, but it is not one

The Domain Model should be recognisable and understandable by the business

That’s a Lot of BitsThat’s a Lot of Bits

AggregatesAggregates

“An aggregate is a collection of items that are gathered together to form a total quantity” - Wikipedia

An Aggregate Root is the root item containing a number of parts that form a whole

An AR is more likely to match a Use Case than any model structure

“An aggregate is a collection of items that are gathered together to form a total quantity” - Wikipedia

An Aggregate Root is the root item containing a number of parts that form a whole

An AR is more likely to match a Use Case than any model structure

Everyone Loves an Event!

Domain EventsDomain Events

The “3rd Thing” in DDDLike all events, notification that

“something happened”They are in the past tense, and

should be named accordinglyClosely aligned to your Domain

ModelWill probably be handled by your

messaging layer

The “3rd Thing” in DDDLike all events, notification that

“something happened”They are in the past tense, and

should be named accordinglyClosely aligned to your Domain

ModelWill probably be handled by your

messaging layer

Bounded ContextsBounded Contexts

When you have multiple models you should consider Bounded Contexts

Each BC is a self contained “mini application” containing it’s own model, persistence and code base

Within a BC, everything should be strictly consistent

To map between BCs you use a Context Map

When you have multiple models you should consider Bounded Contexts

Each BC is a self contained “mini application” containing it’s own model, persistence and code base

Within a BC, everything should be strictly consistent

To map between BCs you use a Context Map

Transformer Domain

Vehicle Domain

Context MapsContext Maps

A Context Map provides a clearly defined relationship between Bounded Contexts and the interactions between their Domain Models

A Context Map may be represented in many forms, but it comprises the rules for how to turn A into B

A Context Map provides a clearly defined relationship between Bounded Contexts and the interactions between their Domain Models

A Context Map may be represented in many forms, but it comprises the rules for how to turn A into B

Persistence IgnorancePersistence Ignorance

Subtitled “There Is No Database” DDD uses the Repository pattern

to create Persistence IgnoranceA Repository represents itself as

an in-memory list of itemsRepositories are specific to

Aggregate Roots, not to Entities

Subtitled “There Is No Database” DDD uses the Repository pattern

to create Persistence IgnoranceA Repository represents itself as

an in-memory list of itemsRepositories are specific to

Aggregate Roots, not to Entities

Anti-Corruption LayersAnti-Corruption Layers

An Anti-Corruption Layer is a method to isolate two systems, allowing systems to be integrated without knowledge of each other

An ACL presents a Facade to both systems, defined in terms of their specific models

ACLs maintain the integrity of a Domain

An Anti-Corruption Layer is a method to isolate two systems, allowing systems to be integrated without knowledge of each other

An ACL presents a Facade to both systems, defined in terms of their specific models

ACLs maintain the integrity of a Domain

Factors For Success of DDD

Factors For Success of DDD

Your domain is not trivialYou have access to Domain

ExpertsYou have an iterative processYou have a skilled and motivated

team

Your domain is not trivialYou have access to Domain

ExpertsYou have an iterative processYou have a skilled and motivated

team

Where Does DDD Work Best?

Where Does DDD Work Best?

Domain Driven Design is a way of dealing with complexity

DDD is ideally suited to Behaviour Centric Systems

notData Centric systems

Domain Driven Design is a way of dealing with complexity

DDD is ideally suited to Behaviour Centric Systems

notData Centric systems

Messaging ArchitecturesMessaging Architectures

DDD is ideally suited to Message Based Architectures

DDD is ideally suited to Commands and Events

DDD without Commands and Events is going to be a lot of hard work

DDD is ideally suited to providing multiple autonomous systems that are loosely coupled

DDD is ideally suited to Message Based Architectures

DDD is ideally suited to Commands and Events

DDD without Commands and Events is going to be a lot of hard work

DDD is ideally suited to providing multiple autonomous systems that are loosely coupled

CAP TheoremCAP Theorem

Consistency: The client perceives that a set of operations has occurred all at once.

Availability: Every operation must terminate in an intended response.

Partition tolerance: Operations will complete, even if individual components are unavailable.

You cannot have all three

Consistency: The client perceives that a set of operations has occurred all at once.

Availability: Every operation must terminate in an intended response.

Partition tolerance: Operations will complete, even if individual components are unavailable.

You cannot have all three

ACIDACID

Atomicity, Consistent, Isolation, Durability

Gives you Consistency and Availability

Sacrifices Partition Tolerance

Meaning: ACID systems are hard and expensive to scale

Atomicity, Consistent, Isolation, Durability

Gives you Consistency and Availability

Sacrifices Partition Tolerance

Meaning: ACID systems are hard and expensive to scale

BASEBASE

Basically Available, Soft state, Eventually consistent

Gives you Availability and Partition Tolerance

Sacrifices Consistency

Meaning BASE systems can scale easily and are very fault tolerant

Basically Available, Soft state, Eventually consistent

Gives you Availability and Partition Tolerance

Sacrifices Consistency

Meaning BASE systems can scale easily and are very fault tolerant

BASE at a Database LevelBASE at a Database Level

Most RDBMS databases are ACIDMost NoSQL databases are BASE

The largest expense in database systems is in fault tolerance and scaling

BASE databases scale massively and cheaply

BASE databases are highly fault tolerant

Most RDBMS databases are ACIDMost NoSQL databases are BASE

The largest expense in database systems is in fault tolerance and scaling

BASE databases scale massively and cheaply

BASE databases are highly fault tolerant

BASE at an Architectural Level

BASE at an Architectural Level

Latency is the biggest constraint on architecture

Unless you have pessimistic locking, all data is stale

Most mistakes in developer code are around consistency vs. latency

The main cause of rigidity and fragility in systems is due to trying to maintain consistency

Command Query Responsibility Segregation gives us BASE at an architectural level

Latency is the biggest constraint on architecture

Unless you have pessimistic locking, all data is stale

Most mistakes in developer code are around consistency vs. latency

The main cause of rigidity and fragility in systems is due to trying to maintain consistency

Command Query Responsibility Segregation gives us BASE at an architectural level

Command Query Responsibility Segregation

(CQRS)

Command Query Responsibility Segregation

(CQRS)Bertrand Meyer principle of CQS:

every method should either be a command that performs an action, or a query that returns data to the caller

At an architectural level this means:either issue commands, or issue queries, but never both

And, query from a separate source from your domain commands

Bertrand Meyer principle of CQS:every method should either be a command that performs an action, or a query that returns data to the caller

At an architectural level this means:either issue commands, or issue queries, but never both

And, query from a separate source from your domain commands

CQRS in a PictureCQRS in a Picture

Client

Domain

Command

Persist

Publish

Event Handlers

Event Handlers

Update

Queries

(synchronous no bus)

Domain Persistence Read Model

CQRS in a Simpler PictureCQRS in a Simpler Picture

Domain Read Model

Client

Comm

andsDTO

s

Events

CQRS Useful Only for Scaling?

CQRS Useful Only for Scaling?

CQRS gives us hugely simplified Domain persistence and leaves the Domain free of orthogonal concerns

CQRS lets us focus on real Domain logic CQRS gives us optimised reporting and

querying capability CQRS removes a large amount of the

effort involved in dealing with inconsistent systems pretending to be consistent

CQRS has real business benefits beyond scaling

CQRS gives us hugely simplified Domain persistence and leaves the Domain free of orthogonal concerns

CQRS lets us focus on real Domain logic CQRS gives us optimised reporting and

querying capability CQRS removes a large amount of the

effort involved in dealing with inconsistent systems pretending to be consistent

CQRS has real business benefits beyond scaling

Questions?Jak Charltonjak@thinkddd.comwww.thinkddd.com

Readify www.readify.net