Indice
- Che cos'è il Domain-Driven Design?
- Il ruolo dei modelli specialistici
- DDD Strategico: Suddivisione del dominio
- Modellazione collaborativa
- Cosa non è il DDD
- Conclusione
Come abbiamo spiegato nel nostro articolo "Perchè tanti progetti IT falliscono?", lo sviluppo software non è mai un fine a sé, ma uno strumento per risolvere problemi reali. La tecnologia, in questo contesto, è il mezzo per raggiungere un obiettivo, non l’obiettivo stesso. Per progettare un software efficace, è fondamentale comprendere a fondo i problemi che si vogliono risolvere.
Il cuore della questione è quindi capire le dinamiche del problema per sviluppare un software che non solo funzioni, ma risponda precisamente alle esigenze. Alla fine, un software non rappresenta la conoscenza del dominio, ma ciò che gli sviluppatori hanno capito di esso. Una buona comprensione del dominio diventa quindi la chiave per creare soluzioni mirate, efficaci ed efficienti.
Ma come si può strutturare questa comprensione per affrontare la complessità del software? Il Domain-Driven Design fornisce un approccio pratico, che si divide in due livelli principali: strategico e tattico.
Che cos'è il Domain-Driven Design?
Il Domain-Driven Design, spesso abbreviato in DDD, è un approccio alla progettazione del software introdotto da Eric Evans nel suo libro del 2004 "Domain-Driven Design: Tackling Complexity in the Heart of Software". L’obiettivo del DDD è affrontare la complessità del software concentrandosi sulla comprensione del dominio in cui opera.
Evans propone una serie di concetti e strumenti per rappresentare i domini nel software in modo chiaro e condiviso. L’idea centrale è che uno sviluppo di successo richiede una comprensione profonda e condivisa tra i membri del team interdisciplinare, come sviluppatori, tester ed esperti del dominio.
Punti chiave del DDD:
- Il software deve riflettere le logiche e le strutture del dominio.
- La comunicazione tra sviluppatori ed esperti del dominio è fondamentale.
- La creazione di un linguaggio condiviso (Ubiquitous Language) aiuta a evitare ambiguità e fraintendimenti.
Il DDD opera su due livelli principali:
- Strategico: Si concentra sulla visione d'insieme, suddividendo il dominio in aree ben definite per gestire meglio la complessità.
- Tattico: Fornisce strumenti pratici e pattern per tradurre la comprensione del dominio in codice.
Il ruolo dei modelli specialistici
Per creare software che risolva problemi specifici, i team di sviluppo devono modellare le strutture e le regole del dominio. Questi modelli prendono forma attraverso diagrammi, codice e discussioni. Nel DDD, il modello orientato al dominio è il nucleo del sistema software.
L'importanza dei contesti
Man mano che un modello diventa più grande, aumentano anche le incoerenze. Molti concetti aziendali hanno significati diversi a seconda del contesto, e forzare tutto in un unico modello porta a confusione e rigidità. Per risolvere questo problema, il DDD introduce i contesti delimitati (Bounded Contexts), che suddividono il dominio in modelli più piccoli e indipendenti.
Ad esempio, in un sistema per un cinema, un "biglietto" potrebbe essere:
Un'unità vendibile (con prezzo, sconto, IVA).
Un’autorizzazione di accesso (con validità e condizioni).
Invece di modellare tutto in un unico "biglietto", si creano modelli distinti per ogni contesto. Questo approccio riduce la complessità, rende il software più modulare e migliora la collaborazione nei team.
DDD Strategico: Suddivisione del dominio
Sottodomini
Il primo passo nella progettazione strategica è suddividere il dominio in sottodomini, che rappresentano le diverse aree del business. Questi si classificano in:
- Domini fondamentali (Core Domains): cruciali per il successo dell’azienda. Richiedono attenzione speciale e sviluppo interno.
- Sottodomini di supporto: non centrali, ma essenziali per il funzionamento dei domini fondamentali. Possono essere specifici per l’azienda.
- Sottodomini generici: processi standard, come la contabilità, che non forniscono un vantaggio competitivo. Spesso affidati a software di terze parti.
Questa suddivisione permette di identificare le aree su cui concentrare gli sforzi, evitando di investire risorse dove non necessario.
Contesti delimitati e linguaggio condiviso
I contesti delimitati definiscono confini chiari per ciascun sottodominio. Questi confini sono anche linguistici: ogni contesto usa un linguaggio specifico condiviso dai membri del team. Questo Ubiquitous Language si evolve nel tempo grazie al dialogo continuo tra sviluppatori ed esperti del dominio.
Modellazione collaborativa
La modellazione collaborativa è una pratica fondamentale del DDD. Si tratta di riunire esperti di dominio e team tecnici per sviluppare insieme modelli e definire confini. Tra i metodi più usati ci sono:
Event Storming: Una tecnica per mappare i processi aziendali e identificare eventi chiave.
Domain Storytelling: Raccontare storie per comprendere il flusso delle attività nel dominio.
Example Mapping: Strutturare esempi concreti per chiarire regole e requisiti.
Questi workshop promuovono una comprensione condivisa e migliorano la comunicazione, elementi fondamentali per costruire un software che rispecchi fedelmente il dominio.
Cosa non è il DDD
È importante chiarire alcuni fraintendimenti comuni:
Il DDD non è un framework: Non si tratta di una libreria o di uno strumento predefinito.
Non è obbligatorio implementarlo interamente: Può essere applicato solo dove ha maggiore impatto.
Non è sinonimo di microservizi: Sebbene possa favorire architetture modulari, non richiede necessariamente microservizi.
Il DDD non elimina la complessità, ma aiuta a gestirla attraverso una profonda comprensione del dominio e un linguaggio condiviso.
Conclusione
Il Domain-Driven Design è un approccio che mette al centro la comprensione del dominio per affrontare la complessità del software. Attraverso modelli specialistici, contesti delimitati e linguaggi condivisi, il DDD aiuta i team interdisciplinari a collaborare meglio e a creare software più efficace.
Non è una metodologia rigida, ma un insieme di principi flessibili che possono essere adattati alle esigenze di ogni progetto. Il vero valore del DDD risiede nella capacità di allineare le persone e i concetti, costruendo soluzioni che riflettano fedelmente le logiche del mondo reale. Con l’uso integrato dei livelli strategico e tattico, è possibile affrontare ogni aspetto dello sviluppo con maggiore chiarezza e precisione.
.jpg)
