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

I patterns e le relazioni fra essi, nel progettare del software domain-driven

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.

Artefatti del DDD

Nel libro Domain-Driven Design, che è orientato a descrivere sistemi orientati agli oggetti, vengono introdotti una serie di artefatti per esprimere modelli di dominio nell'ambito di un processo di progettazione domain-driven:

Entity
Un oggetto che non è definito dai suoi attributi, ma piuttosto dalla sua identità. Ad esempio in una biblioteca dove ci interessa identificare ciascuna copia a disposizione degli utenti, i libro è una entity: nonostante il suo stato (disponibile, in prestito, smarrito, etc.) o la sua collocazione su scaffale possano cambiare, quel libro rimane fisicamente lo stesso oggetto.
Value object
Un oggetto che ha una serie di attributi ma non ha identità concettuale. I value object devono essere trattati come oggetti immutabili. Per esempio quando le persone si scambiano banconote da cinque euro, essi sono solo interessati al valore nominale della banconota, non alla singola identità delle banconote scambiate. In questo contesto, le banconote da cinque euro sono un value object: se la persona A ha una banconota da cinque euro, e la persona B ha una banconota da cinque, e le due persone se le scambiano, il loro stato di "possessori di una banconota da cinque euro" non è cambiato, e non cambia indipendentemente da quante volte avviene lo scambio.: In un contesto diverso, come per esempio un sistema bancario, potrebbe essere necessario identificare la singola banconota attraverso il suo numero seriale: in questo contesto la banconota è un'entità, è c'è differenza se un sportello automatico fornisce ad un utente la banconota con il numero di serie 1234 rispetto a quella con numero di serie 1235.
Aggregate
Una collezione di oggetti che sono legati insieme da un'entità padre, nota come aggregate root. L'entità radice di aggregazione incapsula la complessità e mantiene la consistenza dei cambiamenti compiuti all'interno dell'aggregato, proibendo ad oggetti esterni di detenere i riferimenti ai suoi membri interni.: Per esempio, nel contesto di un reparto vendite un ordine può essere composto da più prodotti, e ha un totale che deve sempre corrispondere alla somma dei prezzi dei prodotti inclusi nell'ordine. È utile esprimere l'ordine come aggregate, in modo da poter garantire la consistenza del totale consentendo l'accesso ai prodotti solo tramite l'ordine. L'ordine, aggregate root, ha il compito di ricevere le richieste di modifica dei prodotti provenienti dall'esterno dell'aggregate, e di modificare il totale di conseguenza.
Domain event
Un evento di dominio è un oggetto che rappresenta un evento che ha causato una modifica dello stato di una o più entità. Ad esempio, in una biblioteca, un prestito può essere un evento di dominio, in quanto rappresenta il cambio di stato di un libro da "disponibile" a "in prestito".
Service
Quando un'operazione non appartiene naturalmente a nessun oggetto forzare la sua appartenenza ad un oggetto distorce la coerenza del modello oppure causa un proliferare di oggetti astratti privi di significato di dominio. Queste operazioni devono essere definite in un service, un componente che ha come unica responsabilità lo svolgimento di queste operazioni. Ad esempio, in un sistema ecommerce, il calcolo delle spese di spedizione è un ottimo candidato per essere implementato in un service.
Repository
I repository sono servizi che espongono un'interfaccia per il recupero di oggetti di dominio, astraendo il database sottostante e fornendo metodi che seguono le esigenze del dominio e che sono coerenti con l'ubiquitous language. Ad esempio, un repository di libri per una biblioteca potrebbe esporre i metodi libriInPrestito e libriDisponibili .
Factory
Le factory sono oggetti all'interno del dominio che hanno il compito astrarre la creazione di oggetti o aggregati complessi e difficili da costruire, rendendo più facile creare questi oggetti ed evitando di rendere i client che eseguono la creazione troppo dipendenti dalla struttura interna e dalle regole di questi oggetti.

Svantaggi

Al fine di mantenere il modello come un costrutto del linguaggio puro e utile, il team deve tipicamente implementare l'isolamento con grande attenzione e prestare attenzione all'incapsulamento all'interno del modello di dominio. Di conseguenza, un sistema costruito attraverso il Domain Driven Design può essere oneroso in termini di costo di sviluppo.

Quindi un sistema basato sul Domain Driven Design ha un costo relativamente alto. Il Domain Driven Design offre certamente numerosi vantaggi tecnici, ad esempio la manutenibilità, Microsoft raccomanda comunque di applicarlo solo ai domini complessi in cui il modello e i processi linguistici offrono evidenti vantaggi nella comunicazione di informazioni complesse, e nella formulazione di una visione comune del dominio.

Note

Voci correlate

Collegamenti esterni

Estratto da "https://it.wikipedia.org/w/index.php?title=Domain-driven_design&oldid=143103471"
Uses material from the Wikipedia article Domain-driven design, released under the CC BY-SA 4.0 license.