Articoli di programmazione
Domain Driven Design: piccola introduzione
Cosa è il DDD, quali sono i concetti chiave e soprattutto come può aiutarci a scrivere applicazioni migliori
Per DDD si intende Domain Driven Design, ovvero un design del software basato sul Dominio di Business (Business Model). E' un insieme di termini, concetti, regole, consigli e pattern che funge da riferimento per sviluppare applicazioni: non è un pattern applicativo nel senso stretto del termine.
DDD si basa sul Dominio di Business. Il Dominio di Business è l'insieme di oggetti, ovvero di classi, che riflette nella nostra applicazione le entità che si trovano nel modello di business per cui l'applicazione è stata sviluppata. Per esempio in ogni software e-commerce, oggetti come Carrello o Ordine, sono oggetti del dominio di business, perché riflettono entità di lavoro reali, (presenti nel modello di business) cioè l'ordine viene evaso dagli spedizionieri ed il carrello origina un ordine.
DDD asserisce che il software deve riflettere il dominio di business, sia come struttura che come linguaggio e consiglia di:
- focalizzare lo sviluppo sul dominio
- basare la propria struttura applicativa su un modello di dominio
- far collaborare tecnici ed esperti del dominio per far evolvere il modello di dominio
Un po' di dizionario DDD:
- Context: il contesto rappresenta il recinto all'interno del quale una certa espressione è valida. Il Context può essere "geografico" ma anche "temporale".
Esempio: un Ordine è modificabile? Dipende dal Context! Se un Ordine è già stato evaso ci troviamo in un Context ben definito per cui un Ordine ormai non è modificabile.
- Model: modello concettuale, astrazione che descrive almeno alcuni aspetti di alcuni oggetti del dominio.
Esempio: una astrazione Ordine, Riga di Ordine, Oggetto che si interfaccia con queste classi ed aggiorna la Giacenza di Magazzino costituisce un Model.
- Ubiquitous Language: un linguaggio basato sulle entità del modello di business, condiviso tra i tecnici, gli esperti del modello di business ed i vari layer applicativi, che devono rispecchiare appunto i nomi e le terminologie utilizzate nel modello di business.
Facciamo il solito esempio con il nostro software e-commerce: se chiami al telefono la segretaria amministrativa e le chiedi di verificare un Ordine lei lo sa fare; sa a cosa ti stai riferendo. Non puoi quindi chiamare in modo diverso l'oggetto Ordine nel software, ad esempio RichiestaMerce, altrimenti crei ambiguità ed incoerenza.
- Bounded Context: il software è costituito da più modelli, ognuno che lavora all'interno del proprio contesto e non deve essere utilizzato al di fuori di esso. Il Bounded Context è il recinto all'interno del quale un modello ha senso di esistere. E' anche qualcosa di fisico, che può riferirsi alla CodeBase o alle Tabelle di Database.
Esempio: La Compilazione di un Carrello costituisce un Bounded Context ed all'interno di esso vigono certe regole, operano diversi modelli che non esistono nel Bounded Context di Registrazione Utente. Alcune entità del dominio, come l'Utente possono esistere sia nel Bounded Context di compilazione del carrello ed in quello di registrazione utente, ma essendo in modelli diversi possono avere diversi significati, esporre diversi comportamenti o addirittura, non è obbligatorio assolutamente, ma è comunque possibile, essere fisicamente rappresentati da classi diverse che si collegano a tabelle diverse. Magari nella Compilazione dell'Ordine l'utente è solo una classe che espone la EMail, Nome e Cognome; mentre nella Registrazione Utente l'utente è un aggregato ch contiene Indirizzo, Dati Fiscali, Foto, Dati di Autenticazione, etc.
- Context Map: la mappa dei diversi Bounded Contexts che esistono all'interno della nostra applicazione.
Elementi costitutivi dell'architettura:
- Entity: un oggetto, che spesso rappresenta un entità del dominio, contraddistinto dalla presenza di un ID. ID è l'identificativo e può essere di qualunque tipo (intero, Guid, stringa, etc.) l'importante è che sia univoco a livello di applicazione. Un Utente è una Entity con un suo IDUtente univoco.
- Value Object: un oggetto di tipo valore, che non ha ID e dovrebbe essere trattato come immutabile (questo è un consiglio).
Un ottimo esempio di Value Object è un oggetto Ammontare. l'Ammontare di denaro è un oggetto che non ha ID e può essere rappresentato dalle seguenti proprietà: Cifra, Valuta, Decimali. Quando hai bisogno di creare un Ammontare da associare alla tua riga di ordine, crei una istanza di Ammontare che puoi così linkare alla riga di ordine senza bisogno di dagli un ID. Che senso avrebbe dire che il tuo ammontare di 10 Euro a 2 decimali ha un ID diverso da un altro ammontare sempre di 10 Euro a 2 decimali?
In C# i Value Objects sono rappresentati dalle Struct.
- Aggregate: oggetti di dominio, facenti parte di un modello, spesso operano insieme e da soli avrebbero poco senso. Ordine, Riga di Ordine, Informazioni di Spedizione sono 3 entità di dominio che operano insieme e dal punto di vista logico ed architetturale sono spesso trattate come unica super-entità: un Aggregate appunto.
Spesso le validazioni sono effettuate a livello di Aggregate: un Ordine senza righe o senza informazioni di spedizione non sono validi.
Un Aggregate può includere anche altri elementi oltre alle entità di dominio, ad esempio in certe architetture può includere il Repository che gestisce la persistenza dell'Aggregate stesso.
- Domain Event: un evento di dominio è un evento importante per gli esperti del business model.
Esempio: un utente si de-registra dal sistema. Cancellandosi non riceverà più la Newsletter e non potrà più creare ordini. Questo evento dovrà scatenare alcune operazioni a cascata che il software deve organizzare ed eseguire.
Tutto questo che hai appena letto costituisce la base per comprendere cosa è DDD. A valle di tutto ciò si sviluppano pattern più o meno conosciuti ed estesi, dal CQRS all'Event Sourcing, che nel linguaggio comune sono ormai correlati al DDD, perché spesso sono semplicemente la logica conseguenza delle regole di buon senso dettate dal DDD.
#programmazione #ddd #architettura
DDD si basa sul Dominio di Business. Il Dominio di Business è l'insieme di oggetti, ovvero di classi, che riflette nella nostra applicazione le entità che si trovano nel modello di business per cui l'applicazione è stata sviluppata. Per esempio in ogni software e-commerce, oggetti come Carrello o Ordine, sono oggetti del dominio di business, perché riflettono entità di lavoro reali, (presenti nel modello di business) cioè l'ordine viene evaso dagli spedizionieri ed il carrello origina un ordine.
DDD asserisce che il software deve riflettere il dominio di business, sia come struttura che come linguaggio e consiglia di:
- focalizzare lo sviluppo sul dominio
- basare la propria struttura applicativa su un modello di dominio
- far collaborare tecnici ed esperti del dominio per far evolvere il modello di dominio
Un po' di dizionario DDD:
- Context: il contesto rappresenta il recinto all'interno del quale una certa espressione è valida. Il Context può essere "geografico" ma anche "temporale".
Esempio: un Ordine è modificabile? Dipende dal Context! Se un Ordine è già stato evaso ci troviamo in un Context ben definito per cui un Ordine ormai non è modificabile.
- Model: modello concettuale, astrazione che descrive almeno alcuni aspetti di alcuni oggetti del dominio.
Esempio: una astrazione Ordine, Riga di Ordine, Oggetto che si interfaccia con queste classi ed aggiorna la Giacenza di Magazzino costituisce un Model.
- Ubiquitous Language: un linguaggio basato sulle entità del modello di business, condiviso tra i tecnici, gli esperti del modello di business ed i vari layer applicativi, che devono rispecchiare appunto i nomi e le terminologie utilizzate nel modello di business.
Facciamo il solito esempio con il nostro software e-commerce: se chiami al telefono la segretaria amministrativa e le chiedi di verificare un Ordine lei lo sa fare; sa a cosa ti stai riferendo. Non puoi quindi chiamare in modo diverso l'oggetto Ordine nel software, ad esempio RichiestaMerce, altrimenti crei ambiguità ed incoerenza.
- Bounded Context: il software è costituito da più modelli, ognuno che lavora all'interno del proprio contesto e non deve essere utilizzato al di fuori di esso. Il Bounded Context è il recinto all'interno del quale un modello ha senso di esistere. E' anche qualcosa di fisico, che può riferirsi alla CodeBase o alle Tabelle di Database.
Esempio: La Compilazione di un Carrello costituisce un Bounded Context ed all'interno di esso vigono certe regole, operano diversi modelli che non esistono nel Bounded Context di Registrazione Utente. Alcune entità del dominio, come l'Utente possono esistere sia nel Bounded Context di compilazione del carrello ed in quello di registrazione utente, ma essendo in modelli diversi possono avere diversi significati, esporre diversi comportamenti o addirittura, non è obbligatorio assolutamente, ma è comunque possibile, essere fisicamente rappresentati da classi diverse che si collegano a tabelle diverse. Magari nella Compilazione dell'Ordine l'utente è solo una classe che espone la EMail, Nome e Cognome; mentre nella Registrazione Utente l'utente è un aggregato ch contiene Indirizzo, Dati Fiscali, Foto, Dati di Autenticazione, etc.
- Context Map: la mappa dei diversi Bounded Contexts che esistono all'interno della nostra applicazione.
Elementi costitutivi dell'architettura:
- Entity: un oggetto, che spesso rappresenta un entità del dominio, contraddistinto dalla presenza di un ID. ID è l'identificativo e può essere di qualunque tipo (intero, Guid, stringa, etc.) l'importante è che sia univoco a livello di applicazione. Un Utente è una Entity con un suo IDUtente univoco.
- Value Object: un oggetto di tipo valore, che non ha ID e dovrebbe essere trattato come immutabile (questo è un consiglio).
Un ottimo esempio di Value Object è un oggetto Ammontare. l'Ammontare di denaro è un oggetto che non ha ID e può essere rappresentato dalle seguenti proprietà: Cifra, Valuta, Decimali. Quando hai bisogno di creare un Ammontare da associare alla tua riga di ordine, crei una istanza di Ammontare che puoi così linkare alla riga di ordine senza bisogno di dagli un ID. Che senso avrebbe dire che il tuo ammontare di 10 Euro a 2 decimali ha un ID diverso da un altro ammontare sempre di 10 Euro a 2 decimali?
In C# i Value Objects sono rappresentati dalle Struct.
- Aggregate: oggetti di dominio, facenti parte di un modello, spesso operano insieme e da soli avrebbero poco senso. Ordine, Riga di Ordine, Informazioni di Spedizione sono 3 entità di dominio che operano insieme e dal punto di vista logico ed architetturale sono spesso trattate come unica super-entità: un Aggregate appunto.
Spesso le validazioni sono effettuate a livello di Aggregate: un Ordine senza righe o senza informazioni di spedizione non sono validi.
Un Aggregate può includere anche altri elementi oltre alle entità di dominio, ad esempio in certe architetture può includere il Repository che gestisce la persistenza dell'Aggregate stesso.
- Domain Event: un evento di dominio è un evento importante per gli esperti del business model.
Esempio: un utente si de-registra dal sistema. Cancellandosi non riceverà più la Newsletter e non potrà più creare ordini. Questo evento dovrà scatenare alcune operazioni a cascata che il software deve organizzare ed eseguire.
Tutto questo che hai appena letto costituisce la base per comprendere cosa è DDD. A valle di tutto ciò si sviluppano pattern più o meno conosciuti ed estesi, dal CQRS all'Event Sourcing, che nel linguaggio comune sono ormai correlati al DDD, perché spesso sono semplicemente la logica conseguenza delle regole di buon senso dettate dal DDD.
#programmazione #ddd #architettura