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…