(articolo redatto da Maurizio Migliore)
Il successo di un progetto non sta solo nelle tecnologie adottate.
Negli anni ’90, è diventato evidente che il successo dei progetti software non dipende solo dalla tecnologia utilizzata, ma soprattutto dalla comprensione del dominio di business. Ciò ha portato alla ricerca di metodi per affrontare la complessità del dominio e migliorare la comunicazione tra esperti del dominio e sviluppatori.
Project management e DDD
Le metodologie agili, con il loro focus sulla collaborazione e sulla risposta al cambiamento, hanno fornito un terreno fertile per l’adozione del Domain-Driven Design (DDD). La metodologia incoraggia la collaborazione tra esperti del dominio e sviluppatori, promuove il pensiero critico e flessibile e si adatta alle esigenze in evoluzione del business.
Le esperienze di progetto hanno svolto un ruolo importante nello sviluppo del DDD. Esperti del dominio come Eric Evans hanno identificato le sfide comuni, come la comprensione del dominio e la gestione del cambiamento, e hanno contribuito a definire i principi e le pratiche del DDD.
DDD: concetti fondamentali
Il Domain-Driven Design (DDD) è un approccio allo sviluppo del software che si concentra sullo studio e sulla modellazione del dominio del problema, ovvero l’area specifica di conoscenza o di attività che il software deve affrontare.
Sostiene che quando affrontiamo un problema complesso nel contesto di un’applicazione, non possiamo rappresentarlo con un unico modello software. Questo perché i concetti di business possono avere significati e comportamenti diversi a seconda delle situazioni in cui vengono utilizzati.
Ecco alcuni dei concetti chiave del DDD:
- Dominio: il dominio rappresenta l’ambito di applicazione del problema che l’applicazione deve risolvere. È l’area di conoscenza in cui operano gli esperti del dominio, come gli utenti finali o gli stakeholder. Il DDD mette in evidenza l’importanza di comprendere a fondo il dominio e di tradurlo in un modello concettuale all’interno dell’applicazione.
- Modello del dominio: il modello del dominio è una rappresentazione strutturata del dominio del problema. È una descrizione del dominio in termini di entità, valori, relazioni e regole. Il modello del dominio viene creato in collaborazione con gli esperti del dominio e viene utilizzato come base per lo sviluppo del software.
- Aggregati: gli aggregati sono gruppi di entità correlate che sono trattate come un’unità coesa all’interno del modello del dominio. Un aggregato ha una radice, chiamata radice dell’aggregato, che funge da punto di accesso principale per l’interazione con le entità interne. Gli aggregati aiutano a gestire la consistenza delle entità correlate e definiscono i confini transazionali.
- Bounded Context: rappresenta un limite logico all’interno del dominio in cui un modello del dominio specifico è definito e applicato in modo coerente. Può essere visto come un’area delimitata dell’applicazione in cui un particolare modello del dominio ha significato e regole specifiche. Diversi Bounded Context possono coesistere all’interno di un’applicazione complessa. Per un autonoleggio, “Prenotazione” e “Gestione Flotta” potrebbero essere due esempi di Bounded Contexts.
- Context Map: i Bounded Context sono collegati tra loro attraverso mappe di contesto (Context Map), che definiscono le relazioni, le dipendenze e le interazioni tra i diversi contesti. La mappa di contesto aiuta a comprendere l’intero sistema e le connessioni tra i contesti, consentendo una progettazione e una gestione più efficace dell’architettura del software.
- Ubiquitous Language: è un linguaggio condiviso tra gli sviluppatori e gli esperti del dominio (business-oriented). È un insieme di termini e concetti che sono usati in modo coerente sia nelle conversazioni tra gli esperti del dominio che nelle implementazioni del software. L’obiettivo è creare un linguaggio comune che riduca le ambiguità e favorisca la comprensione reciproca.
- Eventi del dominio: rappresentano fatti significativi che si verificano all’interno del dominio del problema. Possono essere eventi passati o futuri, e vengono utilizzati per registrare o comunicare informazioni rilevanti. Gli eventi del dominio sono spesso utilizzati per creare un’architettura basata sugli eventi, in cui il sistema reagisce agli eventi generati all’interno del dominio.
- Layers: suddivisione logica dell’architettura di un’applicazione in diverse componenti o strati.
- Layer di Interfaccia Utente: Gestisce l’interazione tra l’applicazione e gli utenti o altri sistemi esterni.
- Layer di Applicazione: Gestisce le transazioni, traduce DTOS, coordina le attività dell’applicazione, crea e accede agli oggetti di dominio
- Layer di Dominio: Contiene la conoscenza del dominio, la logica di business e lo stato dell’applicazione.
- Layer di Infrastruttura: Gestisce gli aspetti tecnici dell’applicazione, come la persistenza dei dati e l’interazione con servizi esterni. Supporta tutti gli altri livelli, include repository, adattatori, framework ecc
Fasi del DDD
Il DDD si posiziona nella fase antecedente alla definizione finale dell’architettura del software. È un approccio di alto livello e di tipo top-down, che si concentra sui contesti in cui operano gli oggetti e sulla definizione delle competenze di tali contesti. Si suddivide in due fasi principali: lo Strategic Design e il Tactical Design.
Strategic Design
Lo Strategic Design si concentra sulla rappresentazione generale del dominio e comprende concetti come subdomains (suddivisione del dominio in aree di competenza), bounded contexts, ubiquitous language e context map (mappa delle relazioni tra i bounded contexts).
Lo Strategic Design riguarda la gestione delle interazioni tra diversi Bounded Context all’interno di un’architettura complessa. Si concentra sulla definizione dei limiti dei contesti, delle interfacce dei contesti e delle modalità di comunicazione tra di essi.
Lo Strategic Design è responsabile di affrontare la suddivisione dei domini complessi in contesti ben delimitati e di stabilire le relazioni tra i contesti per garantire coerenza e consistenza nel sistema complessivo.
Tactical Design
Il Tactical Design riguarda la modellazione e l’organizzazione dei componenti all’interno di un singolo Bounded Context. Si concentra sulla definizione delle entità, dei value objects, dei servizi di dominio e degli aggregati per implementare la logica di business specifica del contesto. Il Tactical Design mira a creare un modello di dominio ricco di comportamento, utilizzando pattern e principi per garantire la coesione, l’incapsulamento e la gestione delle dipendenze all’interno del Bounded Context.
Utilizza pattern come Aggregate, Factory, Repository e Specification per garantire la consistenza, la scalabilità e l’estendibilità del sistema, mantenendo un modello di dominio comprensibile e manutenibile.
DDD, microservizi ed architettura esagonale
Il DDD può essere utilizzato come base per l’implementazione di architetture a microservizi (Microservice Architecture – MSA).
La decomposizione dei servizi in microservizi può essere realizzata utilizzando i metodi di decomposition offerti dal DDD, come ad esempio la Business Capabilities Decomposition.
In questo modo, il software può essere suddiviso in componenti indipendenti che si concentrano su specifiche aree di competenza, favorendo la scalabilità e la gestione separata dei servizi. Questo approccio si sposa bene anche con l’architettura esagonale.
Il core del dominio nel DDD può essere considerato il nucleo centrale dell’architettura esagonale, dove risiede la logica di business e il modello del dominio. Gli adattatori e i driver corrispondono ai componenti esterni dell’architettura esagonale, che consentono l’interazione tra il core del dominio e il resto del sistema.
L’uso combinato di DDD e architettura esagonale favorisce una maggiore separazione delle responsabilità, una migliore organizzazione del software e una modellazione accurata del dominio. Questa combinazione può contribuire a creare un’applicazione scalabile, flessibile e manutenibile, che risponde alle esigenze del dominio del problema in modo efficace.
Se anche tu vuoi occuparti di importanti progetti di sviluppo software
dai un’occhiata alle nostre opportunità di lavoro e conosciamoci subito!
