Il Domain Driven Design (DDD) è uno dei pilastri fondamentali dello sviluppo software orientato agli oggetti ed è essenziale comprenderlo a fondo per creare codici che durino nel tempo.
La filosofia alla base del DDD è che il software deve rappresentare fedelmente l’impresa per la quale viene costruito, rendendo chiaro già dal codice come funziona l’organizzazione.
Con il DDD software development, gli sviluppatori possono assicurarsi che il software non solo risponda ai requisiti tecnici ma rifletta anche le operazioni e le logiche di business dell’impresa. Questo approccio mira a creare un linguaggio comune, detto anche obliquo, tra sviluppatori e stakeholder così da ridurre il rischio di causare errori nel progetto.
In questo articolo, esploreremo in dettaglio questi concetti e vedremo come applicare il Domain Driven Design per creare un software che non solo abbia un’ottima usabilità ma che riesca anche a supportare efficacemente le esigenze dell’impresa.
Cos’è il Domain Driven Design?
Prima di esplorare il Domain Driven Design (DDD), è essenziale chiedersi: cos’è un dominio? Un dominio è il soggetto di un sistema o di un’applicazione, ovvero è l’area specifica di conoscenza o di attività sui cui il software si deve basare.
Quindi, ogni dominio rappresenta un’area di conoscenza o attività particolarmente rilevante per l’impresa e su cui l’organizzazione vuole costruire il proprio software. All’interno di un dominio, possiamo poi avere vari sottodomini, che sono specifiche sezioni o componenti dell’applicazione.
Il Domain Driven Design è un approccio allo sviluppo software che si concentra proprio sullo studio e sulla modellazione del dominio. Introdotto da Eric Evans nel suo libro del 2003, “Domain-Driven Design: Tackling Complexity in the Heart of Software”, il DDD propone che il software rifletta accuratamente la realtà dell’organizzazione che lo sviluppa.
Infatti, quando affrontiamo problemi complessi nel contesto di un’applicazione, il DDD software development sostiene che non possiamo rappresentarli con un unico modello. Questo perché i concetti di business possono avere significati e comportamenti diversi a seconda delle situazioni in cui vengono utilizzati. Pertanto, il DDD promuove la creazione di modelli di dominio che catturano queste sfumature e complessità e le rendono chiare all’interno dell’organizzazione.
Per applicare il DDD nel modo giusto è quindi fondamentale comprendere la differenza tra domini e sottodomini. Per capirla meglio prendiamo come esempio la creazione di un software per un e-commerce. In questo caso, possiamo identificare i seguenti domini e sottodomini in questo modo:
– Dominio principale (core domain): rappresenta il cuore del business del negozio online ed è quindi tutto ciò che lo fa funzionare, incluse cose tangibili e intangibili.
– Sottodomini: sono tutte le categorie che si collegano al dominio. Alcune di queste possono essere:
- Account: gestione degli utenti e delle loro credenziali.
- Prodotti: catalogo dei prodotti disponibili per l’acquisto.
- Carrello: gestione degli articoli aggiunti dagli utenti.
- Ordini: processi di acquisto e pagamento.
- Spedizioni: gestione della logistica e della consegna degli ordini.
- Promozioni e Sconti: gestione delle offerte speciali e degli sconti.
Le fasi del Domain Driven Design
Il processo di creazione di un modello secondo il DDD è quindi complesso e necessità dell’aiuto di tutti i membri del team. Vediamo ora nel dettaglio quali sono le fasi dello sviluppo secondo il Domain Driven Design.
Analisi e Divisione degli Eventi
Secondo le regole del DDD software development, prima di iniziare a lavorare su un’applicazione, è fondamentale avere una comprensione chiara di come questa funzioni e di come sia percepita dall’organizzazione. Per questo motivo, l’intero team si deve unire e fare brainstorming su quali sono gli eventi che potrebbero essere mappati all’interno del dominio. Un metodo utile per fare ciò può essere l’Event Storming.
L’Event Storming è una tecnica di modellazione collaborativa utilizzata per esplorare complesse situazioni di business. Consente di identificare e mappare tutti gli eventi significativi che accadono nel dominio in esame. Questa tecnica si basa su un workshop interattivo dove partecipanti di diverse competenze lavorano insieme per capire meglio il funzionamento del sistema.
Vediamo nello specifico come funziona utilizzando come esempio l’e-commerce di prima:
– Preparazione: riunire esperti di dominio, sviluppatori e stakeholder.
– Identificazione degli eventi: utilizzare post-it colorati per rappresentare eventi chiave del dominio, disposti in ordine cronologico.
- Esempio: “Utente si registra”, “Prodotto aggiunto al carrello”, “Ordine completato”.
– Definizione dei comandi: determinare le azioni che causano gli eventi.
- Esempio: “Registrati”, “Aggiungi al carrello”, “Completa l’ordine”.
– Identificazione degli aggregati: raggruppare gli eventi correlati per definire gli aggregati. Durante queste fase, strumenti di intelligenza artificiale come Chat GPT o Claude AI possono essere di grande aiuto.
- Esempio: aggregato “Ordine” che contiene eventi come “Prodotto aggiunto” e “Pagamento effettuato”.
– Mappe dei processi: creare mappe che mostrino come gli eventi e i comandi si relazionano all’interno del sistema.
– Linguaggio obliquo: decidere con tutti i membri del team un linguaggio che sia comune per tutti.
Creazione di un Modello di Dominio
A questo punto, per rispondere alla complessità del software è necessario creare un modello di dominio. Questo sarà un’astrazione semplificata e strutturata che serve a mappare e documentare tutto ciò che c’è dentro a un dominio e soprattutto a mettere d’accordo tutti i membri del team. Perché sia efficace, deve essere vincolante e quindi dovrà essere utilizzato il linguaggio obliquo, che gli sviluppatori dovranno rispettare ed implementare come documentato.
Le fasi da attuare per ridurre la complessità del modello sono due: progettazione strategica e progettazione tattica. Vediamole nel dettaglio.
Progettazione Strategica
La progettazione strategica nel Domain-Driven Design (DDD) ha come obiettivo la riduzione della complessità del software attraverso la suddivisione del dominio in contesti delimitati e la definizione delle relazioni tra di essi. Questa fase è cruciale per gestire la complessità delle associazioni tra gli oggetti e per permettere una modellazione efficace e chiara.
La progettazione strategica si articola in:
- Contesti delimitati (bounded contexts): la suddivisione del modello in sottomodelli distinti permette di costruire, testare e ottimizzare ogni sottomodello in modo indipendente. In pratica, ogni contesto delimitato rappresenta una specifica area del dominio che può essere gestita autonomamente. Questa suddivisione è particolarmente utile nei microservizi, dove ogni servizio può rappresentare un contesto delimitato. Nel caso dell’e-commerce, un contesto “Account” può gestire solo gli utenti e le loro credenziali, mentre un contesto “Ordini” può gestire gli ordini e i relativi processi.
- Mappa di contesto (context map): la mappa di contesto sottolinea quali domini comunicano tra di loro, come comunicano e in quale direzione. Questa mappa aiuta a definire nomi e confini chiari per ciascun contesto, facilitando la comprensione delle interazioni tra diverse parti del sistema. Ad esempio, la mappa di contesto può mostrare che il contesto “Ordini” comunica con il contesto “Spedizioni” per aggiornare lo stato della consegna.
- Relazioni tra contesti: le relazioni tra i contesti non solo influenzano dati e funzionalità, ma anche il modo in cui le squadre di sviluppo interagiscono tra di loro. Alcune strategie includono:
- Client-Server: una squadra agisce come cliente per un’altra squadra.
- Condivisione di modelli: parti dello stesso modello sono condivise tra più squadre.
- Anti-corruption layer: uno strato anticorruzione viene creato per mantenere il modello focalizzato sul dominio principale e tradurre tra modelli diversi.
Progettazione Tattica
La progettazione tattica riguarda la creazione di una visione dettagliata del modello di dominio. Questa fase include la definizione dei componenti di base del modello e l’organizzazione in diverse categorie che sono:
- Entità (entities): le entità sono classi che rappresentano oggetti con un’identità unica e ben definita. Ad esempio, un prodotto che ha un nome e un prezzo può essere identificato in modo univoco da un ID.
- Oggetti valore (value objects): gli oggetti valore sono classi senza identità propria, la cui esistenza è legata a un’altra entità. Questi oggetti aggiungono dettagli alle entità principali. Un esempio di oggetto valore può essere un indirizzo legato a un utente.
- Associazioni (associations): le associazioni rappresentano le relazioni tra due classi. Nel caso dell’e-commerce l’associazione la si ha con un ordine che può contenere uno o più prodotti.
- Aggregati (aggregates): gli aggregati sono gruppi di entità con una relazione forte tra loro. Definiscono anche i confini transazionali per garantire la coerenza dei dati. Ad esempio, un ordine può essere la radice dell’aggregato contenente le voci dell’ordine.
- Fabbriche (factories): le fabbriche sono metodi o classi utilizzate per creare aggregati o entità. Forniscono un modo per centralizzare la logica di creazione di oggetti complessi.
- Depositi (repositories): i depositi forniscono metodi per trovare istanze specifiche delle entità, evitando di caricare le entità stesse con troppa responsabilità.
- Servizi (services): i servizi rappresentano operazioni senza stato che svolgono compiti specifici definiti dal modello. Non hanno altre associazioni e sono autonomi nel modello.
Mappatura dell’Architettura
Dopo aver definito i modelli di dominio attraverso la progettazione strategica e tattica, è possibile iniziare a mappare l’architettura del sito. Questo può essere fatto utilizzando varie architetture, come l’architettura orizzontale o il modello a tre livelli (3-Tier). L’obiettivo è organizzare i componenti del software in modo che rispecchino il modello di dominio e facilitino la scalabilità, la manutenzione e l’evoluzione del sistema.
Riepilogo: Esempio di E-commerce
Ricapitoliamo le fasi del Domain Driven Design riprendendo l’esempio di prima dell’e-commerce. I passaggi saranno quindi:
- Definizione del dominio e sottodomini:
- Dominio principale: funzionamento del negozio online.
- Sottodomini: Account, Prodotti, Carrello, Ordini, Spedizioni, Promozioni e Sconti.
- Event Storming:
- Identificazione degli eventi chiave come “Utente si registra”, “Prodotto aggiunto al carrello”, “Ordine completato”.
- Definizione dei comandi come “Registrati”, “Aggiungi al carrello”, “Completa l’ordine”.
- Raggruppamento degli eventi in aggregati come “Utente”, “Carrello”, “Ordine”.
- Modellazione del dominio:
- Creazione di entità come “Utente”, “Prodotto”.
- Definizione di oggetti valore come “Indirizzo”.
- Stabilimento di associazioni tra classi, ad esempio tra “Ordine” e “Prodotti”.
- Utilizzo di aggregati per raggruppare entità correlate, con “Ordine” come radice dell’aggregato.
- Progettazione strategica e tattica:
- Definizione dei contesti delimitati per ciascun sottodominio.
- Creazione di mappe di contesto per evidenziare le interazioni tra i domini.
- Implementazione di fabbriche, depositi e servizi per facilitare la gestione delle entità e dei processi del dominio.
- Mappatura dell’architettura:
- Progettazione dell’architettura del sistema utilizzando modelli come l’architettura orizzontale o il modello 3-Tier per garantire una struttura solida e scalabile.
Questo esempio dimostra quindi come il DDD possa essere applicato in modo efficace per gestire la complessità di un negozio online, garantendo chiarezza, coerenza e durata nel tempo del progetto software.
Conclusione
Il Domain-Driven Design (DDD) è quindi un approccio fondamentale per affrontare la complessità nello sviluppo del software. Progettare un modello di dominio chiaro e ben strutturato è essenziale per costruire applicazioni robuste e durature.
Proprio come il DDD si basa sulla collaborazione tra tutte le menti del team per creare soluzioni efficaci e rappresentative del business, noi di Neting affrontiamo i progetti unendo l’expertise dello sviluppo e del reparto marketing. Questo approccio integrato ci permette di garantire eccellenza in ogni fase del progetto, assicurando che il risultato finale sia non solo tecnicamente solido, ma anche allineato con gli obiettivi di business.
Se hai bisogno di supporto per implementare il Domain-Driven Design o per qualsiasi altra necessità legata allo sviluppo software, contattaci. Siamo qui per aiutarti a migliorare la tua presenza online con soluzioni innovative e personalizzate.
