Software solido e usabile

Transcript

1 La tecnica di analisi e progetto Domain-Driven Design Software solido e usabile 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 Dominio applicativo: cargo shipping, logistica 3

4 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 DB-oriented 4 Side effects YOURLOGO by

5 Senza componente di dominio esplicita cosa si perde? Quali concetti del problema non emergono da questo design? Itinerario, tratte Regole di prenotazione delle spedizioni (booking rules) Policy di overbooking Modello di costo, sconti, tipi di clienti, etc. Il design invece rende espliciti concetti di infrastruttura Tabelle, righe, colonne, id, record, query Tali concetti tecnici sono intrecciati con concetti di dominio 5

6 Un modello di dominio esplicito class Deep model Cargo - volume -cargos 1..* «enumerati... LegType MARITTIME AERIAL RAIL 1 VoyageRoutingServ ice + FindQuickestRoute() + FindCheapestRoute() Voyage - dest - orig - maxcapacity + TotalCost() Route -mainroute - cost 1 1..* -alternativeroute 1 - cost - dest - orig Leg 6

7 Il dominio come responsabilità architetturale Componente di dominio Responsabilità architetturali su: 1. Rappresentazione del problema 2. Soddisfacimento di bisogni specifici componente di dominio deve rimanereseparata da Infrastruttura e aspetti tecnologici (es. database) Vincoli legati a soluzioni preesistenti (codice legacy) 7

8 Un architettura di riferimento per il DDD La componente di dominio forza la separazione tra la rappresentazione del problema e le decisioni 8 tecnologiche Attenzione alle dipendenze! Control Logic class System Architecture DDD User Interface Application Controller Domain B u s i n e s s Logic Infrastructure Technology View Model Persistent Model Presentation Logic Qui è dove succedono le cose interessanti

9 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 9

10 Modelli profondi Il linguaggio ubiquo esplicita conoscenza profonda sul dominio del problema costruendo modelli in cui tale conoscenza si riflette sulla soluzione Modelli profondi danno forma alla conoscenza profonda riducendo lo scollamento tra analisi e progetto 10

11 Aggregati Voyage deve contenere tutti i servizi di accesso alle sue parti utili all esterno Se qualche parte viene fornita come output, ne viene restituita sempre una copia (Value Object) class Cargo3 BookingServ ice Voyage - origin :Place - destination :Place - maxcapacity :long Cargo - size :double CargoOv erbookingpolicy 0..* 1..* Leg - origin :Place - destination :Place + IsAllowed() 11

12 Factory e Repository Factory e Repository isolano le dipendenze di creazione e persistenza Effetti: class Cargo4fr Cargo - size :double 0..* CargoOv erbookingpolicy + IsAllowed() 1..* Leg - origin :Place - destination :Place Nessuna query nel dominio Voyage Nessuna allocazione esplicita della memoria nel codice applicativo - origin :Place - destination :Place - maxcapacity :long Granularità: Una factory e un repository per ogni aggregato BookingServ ice «create» VoyageFactory VoyageRepository 12

13 Architettura stratificata in stile DDD class System Architetcture DDD Complete User Interface View Application Controller Serv ice Domain Aggregate Factory AbstractRepository Infrastructure 13 OracleRepository PostgreSQLRepository

14 Port and Adapters: una moderna architettura DDD 14

15 Difendersi dal codice legacy: il pattern ACL Una strategia efficace per gestire il codice legacy (Big Ball of Mud?) è creare un Anti-Corruption Layer 15

16 Conclusioni: Perché fare DDD? DDD non è solo un approccio tecnico Indagando profondamente la natura del problema e rappresentandolo separatamente dalle decisioni tecnologiche l obiettivo del DDD è di Ridurre la frattura tra analisi e design 16