Domain-driven design

Domain-driven design (DDD) è un approccio alla progettazione del software che punta a riprodurre a livello del software un dominio applicativo, basandosi sull'input degli esperti di quel dominio. Il DDD punta a suddividere i sistemi in contesti delimitati, ciascuno con il proprio modello, piuttosto che a progettare un singolo modello onnicomprensivo.

Seguendo i principi del domain-driven design la struttura e il linguaggio del software dovrebbero corrispondere alla struttura e al linguaggio del dominio. Ad esempio, in una software che si occupa di gestire una cantina vinicola possono esistere classi come "bottiglia" oppure "mosto" e metodi come "applica etichetta" oppure "imbottiglia".

I processi DDD si basano su tre principi cardine:

focalizzare il progetto attorno al dominio e alla logica di dominio;

basare la progettazione di sistemi complessi sui modelli del dominio;

mantenere una collaborazione tra tecnici ed esperti di dominio per rifinire in maniera iterativa modelli concettuali che possano essere applicati ai problemi del dominio.

Il termine "Domain-driven design" è stato coniato da Eric Evans nel 2003 nel libro omonimo.

Definizioni fondamentali

Dominio

Il contesto di conoscenza (ontologia), influenza, o attività, in cui è inserito il software, e sulle quali logiche il software lavora.

Modello

Un sistema di astrazioni che descrive specifici aspetti del dominio, e che può essere usato per risolvere problemi relativi al dominio.

Ubiquitous language

Una terminologia comune basata sul dominio e condivisa tra tutto il team che si occupa della progettazione, e che è utilizzata in tutte le attività che coinvolgono il software.

Strategie nel domain-driven design

Idealmente, è preferibile avere un singolo modello unificato. Anche se questo è un nobile proposito, nella realtà ci dobbiamo tipicamente scontrare con più modelli che coesistono. È utile integrare questa assunzione e lavorare con essa.

Le strategie nel design sono una serie di principi atti a mantenere l'integrità del modello, e che portano a sviluppare il modello di dominio e di interazione tra i vari modelli.

Bounded context

In progetti di grandi dimensioni molti modelli devono interagire tra loro. È facile che la complessità e la molteplicità di interazioni portino a problemi tecnici, di organizzazione e di comunicazione. La strategia del bounded context serve a gestire la complessità di un dominio suddividendolo in aree delimitate e definite, ciascuna con i propri modelli, la propria logica e la propria terminologia. Questo promuove l'indipendenza dello sviluppo all'interno dei singoli contesti, minimizzando i rischi di interferenze tra di loro.

I bounded context servono anche a risolvere il problema della polisemia, cioè la proprietà per una parola di assumere più significati: il contesto in cui un appare un termine determina il suo significato. Ad esempio il "prezzo" per un reparto vendite è una cosa diversa dal "prezzo" per un reparto acquisti. In un approccio DDD la soluzione al problema è segregare ciascun "prezzo" nel suo bounded context, in maniera da limitare le occasioni di fraintendimento, sia nello sviluppo del software concreto, sia nella comunicazione all'interno del progetto.

Continuous integration

Quando più persone lavorano all'interno dello stesso contesto è facile che nascano interpretazioni contraddittorie degli stessi modelli. Il problema cresce con l'aumentare di dimensione del team, ma non è escluso che emerga anche in team poco numerosi. Allo stesso tempo, frammentare il dominio in troppi contesti porta alla perdita di integrazione e di coerenza delle informazioni.

La soluzione è istituire un processo di continuous integration, sia del codice, con l'integrazione frequente delle nuove modifiche con annessi step di testing, sia delle informazioni, con l'esercizio costante dell'ubiquitous language all'interno del team, in modo da mantenere una visione condivisa del modello man mano che la sua concezione evolve nella mente dei singoli membri del team.

Context map

Un singolo contesto delimitato porta ad una serie di problemi in assenza di una visione globale. Il contesto di altri modelli potrebbe essere ancora vago e non completo.

Gli sviluppatori degli altri team potrebbero non essere consapevoli del dominio in cui il contesto opera, quindi la modifica ad un contesto si rende complicata a fronte di confini non ben definiti. Quando interconnessioni tra contesti si rendono necessarie, accade talvolta che i limiti si fondano.

La soluzione è definire ogni modello che esiste nel progetto e definirne i limiti. Questo include modelli impliciti di sotto progetti non object-oriented. Trovare il nome di ogni contesto delimitato, e renderlo parte del linguaggio specifico del dominio. Descrivere i punti di contatto tra i modelli, esplicitando le traduzioni che occorrono nella comunicazione ed evidenziando le condivisioni di informazioni.