SOFTWARE SOLIDO E USABILE

Транскрипт

1 SOFTWARE SOLIDO E USABILE L approccio Domain-Driven Design Nel cuore della complessità del software

2 Che cos è il 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 2

3 Perché una componente di dominio esplicita? Why bother with (domain) models? ˮ The critical complexity of most software projects is in understanding the business domain itself ˮ (Eric Evans) 3

4 Dominio applicativo: cargo shipping, logistica 4

5 Perché una componente di dominio esplicita 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 5 Side effects YOURLOGO by

6 Perché una componente di dominio esplicita class Class Model Voyage Stops class Class Model 0..* start 1 Voyage 1..* Leg stop 1 Stop class Class Model «enumerati... LegType alternativeroute 0..1 MARITTIME AERIAL Voyage Itinerary Leg mainroute * stop 1 start Stop 1 6

7 Pattern tattici del Domain-Driven Design Ubiquitous Language Entity vs. Value Objects Aggregates Factory e Repository Services Modules Domain-Driven Design Tactics 7

8 Ubiquitous Language 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 8

9 Modelli profondi Modelli profondi danno forma alla conoscenza di dominio riducendo lo scollamento tra analisi e progetto 9

10 Modelli profondi Modelli profondi nascono da frequenti iterazioni con esperti di domino per raffinare, estendere e validare il linguaggio ubiquo Se non hai un modello alternativo non hai un modello profondo 10

11 Un modello opaco Esempio: sistema di logistica Regola di business: Il sistema di prenotazione ammette un overbooking del 10% class Cargo Policy cablata nel servizio public int makebooking(cargo cargo, Voyage voyage) { double maxbooking = voyage.capacity() * 1.1; double actualcapacity= voyage.bookedcargosize() + cargo.size(); Voyage - maxcapacity :long 0..* Cargo - size :double } if (actualcapacity > maxbooking) return 1;... return confirmation; 11 BookingManager + makebooking() Quali responsabilità? Nessuna specifica! Quindi troppe!! Regola cablata

12 Modelli profondi: esplicitare la conoscenza di dominio Servizi al posto dei manager Le regole diventano classi class Cargo2 Voyage - maxcapacity :long «Invariant» {sum(cargo.size) < voyage.maxcapacity * 1.1} CargoOv erbookingpolicy + IsAllowed() Cargo - size :double 0..* // BookingService public int makebooking(cargo cargo, Voyage voyage) { if (!overbookingpolicy.isallowed(cargo, voyage)) return 1;... return confirmation; } // CargoOverbookingPolicy public boolean isallowed(cargo cargo, Voyage voyage) { boolean canoverbook= (cargo.size() + voyage.bookedcargosize()) <= (voyage.capacity() * 1.1); } return canoverbook; BookingServ ice 12

13 Pattern strategici del Domain-Driven Design Bounded Context Context Map Relationships between Bounded Contexts SHARED KERNEL CUSTOMER/SUPPLIER CONFORMIST ANTICORRUPTION LAYER OPEN HOST SERVICE PUBLISHED LANGUAGE PARTNERSHIP BIG BALL OF MUD SEPARATE WAYS Domain-Driven Design Strategies 13

14 Bounded Context 14 (Vaughn Vernon)

15 Bounded-Context Identifica un sottodominio specializzato Ubiquitous Language is ubiquitous only inside a context 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

16 Bounded Context (cont.) class BoundedContext Cargo - size :double CargoOv erbookingpolicy + IsAllowed() 0..* Leg - origin :Place - destination :Place 1..* Voyage - origin :Place - destination :Place - maxcapacity :long RoutingServ ice FindBestPathServ ice Graph GraphTrav ersalalgoritm BookingServ ice 16

17 Relazioni tra bounded-context 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 17

18 Relazioni tra bounded-context (cont.) 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 18

19 Relazioni tra bounded-context (cont.) 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 19

20 Context Map Descrive lo stile di collaborazione tra team responsabili di contesti diversi Descrive il livello di interdipendenza tra contesti diversi in un sistema Alberto Brandolini. Strategic Domain Driven Design with Context Mapping. InfoQ

21 Ridurre la fracture tra analisi e implementazione Analista Il sistema dive permettere all'utente di definite le tratte del viaggio Tratta Flag Due record M, Fermata A,... Sviluppatore Una tratta è una coppia di record Fermata. Il primo record è start, Il secondo stop Experts di dominio Flag M, A,... Sviluppatore Il flag M nel record Fermata mi dice che si tratta di una tratta marittima In base al tipo di tratta viene elaborato un modello di costi diverso Tipo di Tratta Cliente Se è presente nel viaggio una tratta marittima, allora il sistema deve fornire un itinerario 22 alternativo Itinerario Array di record Fermata Sviluppatore Un itinerario è un array ordinate di record Fermata