Domain Driven Design è una metodologia e una prescrizione di processo per lo sviluppo di sistemi complessi il cui focus è la mappatura di attività, attività, eventi e dati all'interno di un dominio problematico nei manufatti tecnologici di un dominio di soluzione.
L'enfasi di Domain Driven Design è comprendere il dominio problematico al fine di creare un modello astratto del dominio problematico che può quindi essere implementato in un particolare insieme di tecnologie. Domain Driven Design come metodologia fornisce linee guida su come questo modello di sviluppo e sviluppo tecnologico può tradursi in un sistema che soddisfa le esigenze delle persone che lo utilizzano, pur essendo solido di fronte al cambiamento nel dominio del problema.
Il lato del processo di Domain Driven Design prevede la collaborazione tra esperti di dominio, persone che conoscono il dominio problematico e esperti di progettazione / architettura, persone che conoscono il dominio della soluzione. L'idea è quella di avere un modello condiviso con un linguaggio condiviso in modo tale che quando le persone di questi due diversi domini con le loro due diverse prospettive discutono della soluzione, stanno effettivamente discutendo una base di conoscenza condivisa con concetti condivisi.
La mancanza di una comprensione condivisa del dominio del problema tra le persone che necessitano di un particolare sistema e le persone che progettano e implementano il sistema sembrano costituire un impedimento fondamentale per progetti di successo. Domain Driven Design è una metodologia per affrontare questo impedimento.
È più che avere un modello a oggetti. L'attenzione si concentra davvero sulla comunicazione condivisa e sul miglioramento della collaborazione in modo da poter scoprire le esigenze effettive all'interno del dominio problematico e creare una soluzione adeguata per soddisfare tali esigenze.
Domain-Driven Design: The Good and The Challenging offre una breve panoramica con questo commento:
DDD aiuta a scoprire l'architettura di alto livello e a informare sui meccanismi e le dinamiche del dominio che il software deve replicare. Concretamente, significa che un'analisi DDD ben eseguita minimizza i malintesi tra esperti di dominio e architetti del software e riduce il numero successivo di costose richieste di modifica. Suddividendo la complessità del dominio in contesti più piccoli, DDD evita di costringere gli architetti di progetto a progettare un modello di oggetto gonfio, che è dove si perde molto tempo a elaborare i dettagli dell'implementazione, in parte perché il numero di entità da affrontare spesso aumenta oltre dimensione delle lavagne bianche della sala conferenze.
Vedi anche questo articolo Domain Driven Design for Services Architecture che fornisce un breve esempio. L'articolo fornisce la seguente descrizione in miniatura di Domain Driven Design.
Domain Driven Design sostiene la modellazione basata sulla realtà aziendale rilevante per i nostri casi d'uso. Poiché ora sta invecchiando e il livello di hype diminuisce, molti di noi dimenticano che l'approccio DDD aiuta davvero a comprendere il problema attuale e progetta software per la comprensione comune della soluzione. Durante la creazione di applicazioni, DDD parla di problemi come domini e sottodomini. Descrive passaggi / aree indipendenti di problemi come contesti limitati, enfatizza un linguaggio comune per parlare di questi problemi e aggiunge molti concetti tecnici, come entità, oggetti valore e regole di aggregazione per supportare l'implementazione.
Martin Fowler ha scritto numerosi articoli in cui viene menzionato Domain Driven Design come metodologia. Ad esempio, questo articolo, BoundedContext , offre una panoramica del concetto di contesto limitato di Domain Driven Development.
In quei giorni più giovani ci era stato consigliato di costruire un modello unificato dell'intera azienda, ma DDD riconosce che abbiamo appreso che "l'unificazione totale del modello di dominio per un sistema di grandi dimensioni non sarà fattibile o conveniente" 1 . Quindi, invece, DDD divide un grande sistema in contesti limitati, ognuno dei quali può avere un modello unificato, essenzialmente un modo di strutturare MultipleCanonicalModels.