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


276

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?

Risposte:


595

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).


33
Caspita ... Che bella risposta! Molto apprezzato e la migliore spiegazione che ho letto ovunque di un miglio. Grazie .. Domani scaricherò quel libro.
leen3o,

3
"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." Penso che potrebbe essere un'idea sbagliata qui, l'idea che menzioni è "Valore intero", mentre Aggregate si preoccupa maggiormente del limite delle transazioni, in cui tutte le regole invarianti aziendali devono essere applicate qui.
super1ha1

6
Ad essere onesti, sembra quasi ogni progetto in cui gli sviluppatori collaborano con gli architetti per più di un mese. (Beh, almeno secondo la mia esperienza.) Quale realizzazione mi fa apprezzare ancora di più la tua risposta. :)
Jaroslav Záruba il

4
Non sono d'accordo con l'affermazione secondo cui DDD è "destinato esclusivamente a grandi progetti". DDD è niente che devi fare completamente o per niente. Puoi semplicemente fare alcune pratiche da DDD. Ad esempio, puoi semplicemente fare "Oggetti valore" e "linguaggio onnipresente" e non fare radici aggregate in un piccolo progetto.
EasterBunnyBugSmasher

6
A proposito, non facciamo analisi di dominio per ogni progetto o modello che facciamo. Non abbiamo già conversazioni senza fine come BA con clienti e PMI per comprendere il dominio e l'ambito del progetto? Ancora non capisco cosa sia straordinariamente eccezionale in DDD rispetto a qualsiasi altro progetto di sviluppo software in giro?
supernova,

51

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 .


5
Esiste una versione breve del libro di Eric Evans disponibile gratuitamente .
troelskn,

Il problema è che hai bisogno di qualcuno che capisca il dominio in modo abbastanza astratto da poter dire qualcosa di utile prima di aver legato usando le pagine web! In questo caso, greate!
Ian Ringrose,

3
Ma chi inizierebbe progettando il modulo, onestamente? Qualsiasi corso accademico rispettabile passerebbe attraverso applicazioni di analisi, progettazione e modellizzazione in base alle esigenze aziendali. Non capisco cosa c'è di nuovo in questa tecnica.
Sebas,

6
Anche a me, questo è semplicemente un design orientato agli oggetti, utilizzato da tutti anche prima che arrivasse questo concetto. Non vedo nessuna nuova invenzione qui.
Ronen Festinger,

2
@RonenFestinger, per favore, non giudicare DDD solo per questa risposta. Ci sono molte intuizioni nel libro di Eric Evans. Ad esempio contesti limitati. Il paradigma del contesto limitato è uno dei pilastri dei microservizi che stiamo costruendo oggi. Leggere il libro ti aiuta anche a comprendere i microservizi.
Kerem Baydoğan,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.