Introduzione al Domain Driven Design

Molte cose possono mettere un grande progetto fuori rotta: la burocrazia, obiettivi poco chiari, mancanza di risorse, solo per citarne alcuni, ma è l’approccio alla progettazione che determina in gran parte come il software complesso può diventare.

Quando la complessità sfugge di mano il software non può più essere compreso abbastanza bene per essere facilmente modificato o esteso; al contrario, un buon design può dare opportunità su quelle caratteristiche complesse.

Alcuni di questi fattori di complessità nella progettazione sono di carattere tecnico, ma per molte applicazioni non lo sono, la complessità è nel dominio stesso o l’attività commerciale dell’utente.

Quando questa complessità di dominio non viene affrontata nella progettazione, non importa se la tecnologia infrastrutturale sia ben concepita. Un design di successo deve affrontare sistematicamente questo aspetto centrale del software.

In questi casi un ottimo approccio da valutare è proprio il Domain Driven Design.

Il DDD, termine coniato da Eric Evans nel suo libro dall’omonimo titolo, è un approcio allo sviluppo che ha come obiettivo l’accelerazione e la semplificazione dello sviluppo di progetti complessi.

Sono due le fondamentali premesse da tenere in considerazione:

  1. il principale punto focale va posto sul dominio centrale e sulla logica di dominio;
  2. le progettazioni complesse si devono basare su un modello del dominio.

Per soddisfare l’obiettivo i team di sviluppo e non solo, hanno bisogno di un esteso set di concetti, pratiche, tecniche e principi di design.

Concetti fondamentali

  • Dominio: una sfera di conoscenza. L’argomento al quale l’utente applica un programma è appunto il dominio del software.
  • Modello: un sistema di astrazioni che descrive determinati aspetti di un dominio e che può essere usato per risolvere problemi relativi al dominio.
  • Ubiquitous language: una semantica strutturata attorno al modello del dominio e usato da tutti i membri del team per collegare tutte le attività del team con il software.
  • Context: il contesto nel quale una parola o espressione prende significato.

Gli strumenti e i pattern in un dominio a modelli multipli

Idealmente sarebbe preferibile avere un unico modello unificato.

Sebbene sia un ambizioso obiettivo nella realtà vi sono spesso modelli multipli; è utile perciò accettarlo come dato di fatto e lavorare con esso.

Una progettazione strategica in approccio DDD è un insieme di principi atti a garantire l’integrità del modello, la distillazione del modello di dominio e per lavorare con multipli modelli.

Bounded context

Modelli multipli sono presenti in qualsiasi grande progetto.

Eppure quando si combina codice basato su determinati modelli il software potrebbe diventare inaffidabile e incomprensibile; la comunicazione tra i membri del team potrebbe diventare difficile perché spesso non è chiaro in quale contesto un modello non debba essere applicato.

Perciò è importante definire il contesto (bounded context) in cui si applica un modello; porre dei limiti in termini di organizzazione del team, specificarne l’utilizzo all’interno di specifiche parti dell’applicazione e implementazioni concrete come basi di codice e schemi di database.

Context map

In assenza di una vista globale un singolo bounded context potrebbe creare problemi.

In questo caso i contesti di altri modelli potrebbero essere confusionari e vaghi.

Quindi i membri di altri team non avrebbero consapevolezza dei limiti del contesto e apportando modifiche creerebbero problematiche; infine eventuali connessioni tra diversi contesti creerebbero un caos non indifferente.

E’ importante quindi identificare ogni modello in gioco nel progetto e definire il suo bounded context (includendo i modelli impliciti di un sottosistema non orientato agli oggetti); dare un nome ad ogni bounded context e rendere tali nomi parte della semantica universale; definire i punti di contatto tra i modelli delineando traduzioni per ogni comunicazione e evidenziando ogni condivisione; mappare il terreno.

Continuous integration

Quando diversi membri del team lavorano sullo stesso bounded context, c’è una forte probabilità che il modello si frammenti.

Più grande è il team più grande sarà il problema, ma sono sufficienti anche tre membri di un team per avere seri problemi.

Inoltre dividendo il sistema in context sempre più piccoli si andrà perdendo un livello importante di integrazione e coerenza.

E’ perciò fondamentale utilizzare un sistema di merging del codice che lavori in maniera frequente assieme a test automatizzati; è altrettanto importante esercitare i team a mantenere ed utilizzare una semantica universale, coscienti del fatto che i concetti spesso si evolvono diversamente nella testa delle persone.

Questa era la prima parte di introduzione al D.D.D.; ulteriori concetti e strumenti verranno spiegati nella seconda parte.

Loading Facebook Comments ...
0 commenti

Lascia un Commento

Vuoi partecipare alla discussione?
Fornisci il tuo contributo!

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *