DDD Basics: Bounded Contexts, Modelling - Kortrijk Edition

Post on 11-May-2015

734 Views

Category:

Software

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

Two of the six modules of the @DDDBE meetup on Strategic Domain-Driven Design on June 10, 2014 at Stack & Heap 1. Bounded Contexts 2. Modelling More at http://verraes.net/ or http://twitter.com/mathiasverraes

Transcript

DDD Basics - Kortrijk EditionJune 10, 2014 - Belgium

@DDDBE — http://domaindriven.be

Kindly hosted by

We’ve got some great (international) speakers, but we need locations!

ping @DDDBE

http://domaindriven.be

Aspects of Domain-Driven Design

Tactical DDD !

design patterns

Collaborative DDD !

model storming

Strategic DDD !

complexity, scale

Defining DDD (Yves) Ubiquitous Language (Jef)

Bounded Contexts (Mathias) Context Mapping (Stijn)

Modelling (Mathias) Starting/Selling DDD (Tom)

Q&A / Lean Coffee

Bounded Contexts

“When something is wrong,

something is too big.”

— Leopold Kohr

Large complex systems:

harder to reason about

Large complex systems:

your mental model !=

my mental model

Large complex systems:

subtle nuances in meaning

Avoid a big unified centralised model.

Classic example: What is a product?

Split into Bounded Contexts

Make Bounded Context explicit pure

independent consistent within its

boundary

Benefits: clarity

model integrity freedom to

evolve separately

Drawbacks: short term convenience choosing the boundaries how big is the problem?

Tricks

Inspired by departments

teams life cycles

business processes

What if this was an off-the-shelf solution?

How much communication goes on

between Bounded Contexts?

Visualize! !

Context Mapping Model Storming

Modelling

Structural modelling

describes state

Structural modelling

inspired by persistence concerns

Relational Normalised

CRUD Anaemic

“CRUD is our industry’s

grand failure.”

— Greg Young

Ask your Domain Expert

about State Changes!

Why does it change? When does it change?

How often? Who causes it? By which rules?

What consequences?

!

!

The moving parts are more interesting than the

stable parts

!

!

A Domain Model is about:

state + structure behaviour + change

temporal roles + actors

business rules + invariants causality + correlation

interaction processes

workflows + transitions intention + consequence

failure …

Modelling: Make the implicit explicit

example !

Intentions: Command Objects

Consequences: Domain Events

Intention

ProtectionInterpretation

Automation

user sends Commands

manage processes

domain model sends Events,

guards consistency

create read models from Events

DTO

Commands

Even

ts

@mathiasverraes http://verraes.net

top related