Loading AI tools
Domain-driven design (DDD) è un approccio dello sviluppo del software che risolve problemi complessi connettendo l'implementazione ad un modello in evoluzione. Le premesse del domain-driven sono le seguenti:
Il termine è stato introdotto da Eric Evans nel libro dallo stesso titolo.[1]
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.
In progetti di grandi dimensioni molti modelli devono interagire tra loro. Spesso quando il codice che opera su diversi modelli deve essere integrato il lavoro diventa difficile, facendo emergere bug e rendendo il progetto difficile da comprendere e mantenere. La comunicazione tra i membri del team diventa confusa; diventa quindi poco chiaro a quale contesto un modello è applicato.
La miglior soluzione è definire in maniera esplicita il contesto al quale un modello è applicato; inoltre, è utile esplicitare i confini a livello di organizzazione del team, per chiarire in quali punti dell'applicazione si usa un modello e soprattutto riversare queste assunzioni nell'implementazione. Più di tutto, è fondamentale mantenere il modello coerente all'interno dei limiti posti, non facendosi influenzare e confondere dall'ecosistema che sta intorno.
Quando più persone lavorano allo stesso contesto definito, c'è una forte tendenza a frammentare il modello. Più grosso è il team, più grosso è il problema, anche un team di tre o quattro persone può incontrare problemi. Inoltre frammentare in maniera eccessiva il contesto porta a problemi nell'integrazione e nella coerenza delle informazioni.
La miglior soluzione è istituire un processo frequente di merging del codice con uno step di testing. In questo modo si esercita una costante condivisione della concezione del modello che può evolvere liberamente con i contributi di ogni sviluppatore.
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.
Nel libro Domain-Driven Design[2], vengono introdotti una serie di concetti chiave e pratiche, come il significato ubiquitous language cioè un linguaggio unificato creato dagli esperti del dominio che viene usato per descrivere i requisiti di sistema, che inoltre si adatta all'utilizzo da parte di vari attori quali utenti, produttori e sviluppatori. Il libro è fortemente orientato a descrivere lo strato di dominio in un sistema orientato agli oggetti con un'architettura multistrato. Nel DDD, esistono artefatti per esprimere, creare e recuperare modelli di dominio:
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.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.