Cos'è Domain Driven Design (DDD)? [chiuso]

Continuo a vedere DDD (Domain Driven Design) usato molto negli articoli - Ho letto la voce di Wikipedia su DDD ma ancora non riesco a capire cosa sia effettivamente e come potrei implementarlo nella creazione dei miei siti?

In primo luogo, se non sai di averne bisogno, è possibile che non ne abbia bisogno. Se non riconosci i problemi che DDD risolve, forse non hai questi problemi. Anche i sostenitori del DDD sottolineano spesso che il DDD è destinato solo a progetti di grandi dimensioni (> 6 mesi).

Supponendo che stai ancora leggendo a questo punto, la mia opinione su DDD è questa:

DDD sta cercando di trasformare il tuo software in un modello di un sistema o processo reale. Usando DDD, devi lavorare a stretto contatto con un esperto di dominio in grado di spiegare come funziona il sistema reale. Ad esempio, se stai sviluppando un sistema che gestisce il posizionamento delle scommesse sulle corse dei cavalli, il tuo esperto di dominio potrebbe essere un bookmaker esperto.

Tra te e l'esperto di dominio, costruisci un linguaggio onnipresente (UL), che è fondamentalmente una descrizione concettuale del sistema. L'idea è che dovresti essere in grado di scrivere ciò che il sistema fa in modo che l'esperto di dominio possa leggerlo e verificarne la correttezza. Nel nostro esempio di scommesse, il linguaggio onnipresente includerebbe la definizione di parole come "razza", "scommessa", "probabilità" e così via.

I concetti descritti da UL costituiranno la base della progettazione orientata agli oggetti. DDD fornisce alcune indicazioni chiare su come i tuoi oggetti dovrebbero interagire e ti aiuta a dividere i tuoi oggetti nelle seguenti categorie:

• Oggetti valore, che rappresentano un valore che potrebbe avere parti secondarie (ad esempio, una data può avere un giorno, un mese e un anno)
• Entità, che sono oggetti con identità . Ad esempio, ogni oggetto Cliente ha la sua identità, quindi sappiamo che due clienti con lo stesso nome non sono lo stesso cliente
• Le radici aggregate sono oggetti che possiedono altri oggetti. Questo è un concetto complesso e funziona sulla base del fatto che ci sono alcuni oggetti che non hanno senso se non hanno un proprietario. Ad esempio, un oggetto 'Linea ordine' non ha senso senza un 'Ordine' a cui appartenere, quindi diciamo che l'Ordine è la radice aggregata e gli oggetti Linea ordine possono essere manipolati solo tramite metodi nell'oggetto Ordine

DDD raccomanda anche diversi modelli:

• Repository , un modello per la persistenza (salvataggio e caricamento dei dati, in genere su / da un database)
• Factory , un modello per la creazione di oggetti
• Servizio, un modello per la creazione di oggetti che manipolano gli oggetti del dominio principale senza far parte del dominio stesso

Ora, a questo punto, devo dire che se non hai mai sentito parlare di nessuna di queste cose prima, non dovresti provare a usare DDD su qualsiasi progetto per il quale hai una scadenza. Prima di provare DDD, è necessario conoscere i modelli di progettazione e i modelli di progettazione aziendale . Conoscerli rende DDD molto più facile da comprendere. E, come accennato in precedenza, è disponibile un'introduzione gratuita a DDD da InfoQ (dove puoi anche trovare discussioni su DDD).

Prendi StackOverflow come esempio. Invece di iniziare a progettare alcuni moduli Web, ti concentri prima di fare la modellazione orientata agli oggetti delle entità all'interno del tuo dominio problematico, ad esempio Utenti, Domande, Risposte, Voti, Commenti ecc. Poiché il design è guidato dai dettagli del problema dominio si chiama design guidato dal dominio .

Puoi leggere di più nel libro di Eric Evans .