YOURLOGOby A N D R E A B A R U Z Z O

L’approccioDomain-Driven Design

SOFTWARE SOLIDO E USABILE

Nel cuore della complessità del software

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O2

Che cos’è il Domain-Driven DesignLa tecnica di analisi e progetto Domain-Driven Design

È un approccio alla costruzione di sistemi software

…Usando modelli e (spesso) tecniche OO

…Con una forte connotazione orientata a creare

rappresentazioni esplicite della

componente di dominio

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O3

Perché una componente di dominio esplicita?La tecnica di analisi e progetto Domain-Driven Design

‟Why bother with (domain) models? ˮ

‟The critical complexity of most software projects is in understandingthe business domain itself ˮ

(Eric Evans)

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O4

Dominio applicativo: “cargo shipping”, logisticaLa tecnica di analisi e progetto Domain-Driven Design

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O5

Perché una componente di dominio esplicitaLa tecnica di analisi e progetto Domain-Driven Design

Side-effects-driven design

– Difficile da collaudare, da modificare, da capire

Che conversazione possiamo avere con un esperto di dominio?

Questo modello nasconde requisiti essenziali:

– Regole (business rules, policy, etc.)

– Logica di business

Stile di design tipico

Side effects

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O6

Perché una componente di dominio esplicitaLa tecnica di analisi e progetto Domain-Driven Design

class Class Model

Voyage Stops

0..*

class Class Model

Voyage Leg

Stop

1..*

stop

1

start 1

class Class Model

Voyage Itinerary Leg

«enumerati...

LegType

MARITTIME

AERIAL

Stop

alternativeRoute 0..1

0..*

mainRoute

0..1

stop 1

start

1

YOURLOGOby A N D R E A B A R U Z Z O

Domain-Driven Design Tactics

7

Ubiquitous Language

Entity vs. Value Objects

Aggregates

Factory e Repository

Services

Modules

Pattern tattici del Domain-Driven Design

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O8

Ubiquitous LanguageLa tecnica di analisi e progetto Domain-Driven Design

Molti requisiti si riferiscono a concetti del dominio– Questo linguaggio deve essere preservato nella componente di dominio

Con un linguaggio comune, analisi e design diventano processi di knowledge crunching

Ubiquitous Language Struttura del problema e della soluzione quasi isomorfe

– Piccole modifiche nel dominio hanno basso impatto nella soluzione

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O9

Modelli profondiLa tecnica di analisi e progetto Domain-Driven Design

Modelli profondi danno forma alla conoscenza di dominio

riducendo lo scollamento

tra analisi e progetto

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O10

Modelli profondiLa tecnica di analisi e progetto Domain-Driven Design

Modelli profondi nascono da

frequenti iterazioni con esperti di domino per

raffinare, estendere e validare il linguaggio ubiquo

Se non hai un

modello alternativonon hai un

modello profondo

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O11

Un modello opacoLa tecnica di analisi e progetto Domain-Driven Design

• Esempio: sistema di logistica

• Regola di business: Il sistema di prenotazione ammette un overbooking del 10%

public int makeBooking(Cargo cargo, Voyage voyage)

{double maxBooking = voyage.capacity() * 1.1;

double actualCapacity= voyage.bookedCargoSize() + cargo.size();

if (actualCapacity > maxBooking)return –1;

...return confirmation;

}

class Cargo

BookingManager

+ makeBooking()

Cargo

- size :double

Voyage

- maxCapacity :long0..*

Quali responsabilità?Nessuna specifica!

Quindi troppe!!

Policy cablata nel servizio

Regola cablata

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O12

Modelli profondi: esplicitare la conoscenza di dominioLa tecnica di analisi e progetto Domain-Driven Design

• Servizi al posto dei manager

• Le regole diventano classi// BookingServicepublic int makeBooking(Cargo cargo,

Voyage voyage) {if (!overbookingPolicy.isAllowed(cargo, voyage))

return –1;...return confirmation;

}

// CargoOverbookingPolicypublic boolean isAllowed(Cargo cargo, Voyage voyage) {

boolean canOverbook= (cargo.size() + voyage.bookedCargoSize()) <=

(voyage.capacity() * 1.1);

return canOverbook;}

class Cargo2

Voyage

- maxCapacity :long

Cargo

- size :double

CargoOv erbookingPolicy

+ IsAllowed()

BookingServ ice

«Invariant»

{sum(cargo.size) < voyage.maxCapacity *

1.1}

0..*

YOURLOGOby A N D R E A B A R U Z Z O

Domain-Driven Design Strategies

13

Bounded Context

Context Map

Relationships between Bounded Contexts

SHARED KERNEL

CUSTOMER/SUPPLIER

CONFORMIST

SEPARATE WAYS

Pattern strategici del Domain-Driven Design

ANTICORRUPTION LAYER

OPEN HOST SERVICE

PUBLISHED LANGUAGE

PARTNERSHIP

BIG BALL OF MUD

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O14

Bounded ContextLa tecnica di analisi e progetto Domain-Driven Design

(Vaughn Vernon)

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O

Identifica un sottodominio specializzato

Un BOUNDED CONTEXT è un Dialetto del Linguaggio Ubiquo

– Es. Nella logistica il dominio del routing ha un corrispondente dominio tecnico: percorsi di costo minimo sui grafi

Un BOUNDED CONTEXT isola

conoscenza specialistica

(Informazione contestuale) dentro al dominio applicativo

Bounded-ContextLa tecnica di analisi e progetto Domain-Driven Design

Ubiquitous Language is ubiquitous only inside a

context

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O16

Bounded Context (cont.)La tecnica di analisi e progetto Domain-Driven Design

class BoundedContext

Voyage

- origin :Place

- destination :Place

- maxCapacity :long

RoutingServ iceGraph

GraphTrav ersalAlgoritm

FindBestPathServ ice

Cargo

- size :double

CargoOv erbookingPolicy

+ IsAllowed()

Leg

- origin :Place

- destination :Place

BookingServ ice

0..*

1..*

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O17

Relazioni tra bounded-contextLa tecnica di analisi e progetto Domain-Driven Design

Partnership: coordinated planning of development and joint management of integration

Shared Kernel: intimate interdependency with some subset of the domain model that teams agree to share

Customer-Supplier: two teams in Upstream-Downstream (U-D) relationship: the U team may succeeds interdependently on the fate of the D team (D team has some power to ask for changes in the U model)

– Downstream team: customer

– Upstream team: supplier

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O18

Relazioni tra bounded-context (cont.)La tecnica di analisi e progetto Domain-Driven Design

Anti-Corruption Layer (ACL): defensive translation layer between Bounded Contexts used when control or communication between teams is difficult; isolated layer used to provide the functionality of the U system in terms of the D model

Conformist: two teams in U-D relationship where the U team has no motivation to satisfy the D team’s needs; D team eliminates the complexity of translation between bounded contexts by slavishly adhering to the model of the U team

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O19

Relazioni tra bounded-context (cont.)La tecnica di analisi e progetto Domain-Driven Design

Open Host Services: protocol that give access to the U model as a set of services

Published Language: well-documented, shared language (often combined with OHS) to make the translation between two Bounded Contexts

Separate Ways: two Bounded Contexts with no connection to each other

Big-Ball of Mud: mixed models with inconsistent boundaries where sophisticated modeling is not economically sustainable

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O

Alberto Brandolini. Strategic Domain Driven Design with Context Mapping. InfoQ. 2009. http://www.infoq.com/articles/ddd-contextmapping

21

Context MapLa tecnica di analisi e progetto Domain-Driven Design

Descrive lo stile di collaborazione tra teamresponsabili di contesti diversi

Descrive il livello di interdipendenza tra contesti diversi in un sistema

YOURLOGOby A N D R E A B A R U Z Z Oby A N D R E A B A R U Z Z O22

Ridurre la fracture tra analisi e implementazioneLa tecnica di analisi e progetto Domain-Driven Design

Cliente

Se è presente nel viaggio una tratta marittima, allora il sistema deve fornire un

itinerario alternativo

Itinerario

Sviluppatore

Un itinerario è un array ordinate di record Fermata

Array di record

Fermata

Experts di dominio

In base al tipo di tratta viene elaborato un modello di costi diverso

Tipo di Tratta

Sviluppatore

Il flag ‘M‘ nel record Fermata mi dice che si tratta

di una tratta marittima

Flag ‚M‘, ‚A‘,...

Analista

Il sistema dive permettere all'utente di definite le

tratte del viaggio

Tratta

Flag ‚M‘,

‚A‘,...

Due record

Fermata

Sviluppatore

Una tratta è una coppia di record Fermata. Il primo record è start, Il secondo

stop…