Quali sono le caratteristiche del mio codice DDD (progettazione basata sul dominio)?

Question

Sono nuovo del DDD e sto pensando di utilizzare questa tecnica di progettazione nel mio progetto.

Tuttavia, ciò che mi colpisce del DDD è che l'idea è di base. A differenza di altre tecniche di progettazione come MVC e TDD, non sembra contenere idee innovative. Ad esempio, sono sicuro che alcuni di voi avranno la stessa sensazione che l'idea degli aggregati e dei repository di root non siano una novità, perché quando si scrivono le applicazioni Web MVC è necessario avere un unico oggetto master (ad es. aggregato radice) che contiene altri oggetti minori (ad es. oggetti valore ed entità) nel livello del modello per inviare dati a una vista fortemente tipizzata.

Per me, l'unica idea nuova in DDD è probabilmente il

• entità "intelligenti" (per esempio, si suppone di avere regole di business su aggregati root)
• separazione tra oggetto valore, di aggregazione delle radici e entità.

Qualcuno può dirmi se ho perso qualcosa qui? Se questo è tutto ciò che c'è in DDD, se aggiorno una delle mie applicazioni MVC esistenti con le 2 nuove idee di cui sopra, posso affermare che si tratta di un'applicazione TDD, MVC e DDD?

Answer 1

La risposta breve è che non è quello che sembra il tuo codice che lo qualifica come un progetto DDD, è come sei arrivato a quel codice. Ora per la versione lunga ...

Hai assolutamente ragione che non c'è nulla di rivoluzionario nelle pratiche di codifica DDD, ma con la tua domanda sembra essere un po 'fuori bersaglio. Un errore comune che molti sviluppatori fanno con DDD è quello di concentrarsi troppo sulle pratiche di codifica ignorando alcuni dei concetti più fondamentali di DDD. Fondamentalmente, DDD è una pratica di sviluppo iterativo di un modello con stretta collaborazione tra sviluppatori ed esperti di dominio. Puoi codificare tutti i servizi, le entità e gli oggetti valore che desideri, ma se non stai coinvolgendo esperti di dominio nel processo o non stai migliorando il modello sulle iterazioni, francamente, non stai praticando il DDD. Anche da una prospettiva di codifica, molti considerano i concetti di radici aggregate, contesti limitati e livelli anti-corruzione come strumenti più preziosi dei modelli di base.

Non sei solo nel modo in cui percepisci il DDD. Trovo che quasi tutti gli sviluppatori passino attraverso una fase di DDD in cui stanno cercando di implementare app di esempio utilizzando entità, oggetti di valore e servizi ignorando tutte le altre pratiche che sono fondamentali per DDD. DDD è un processo progettato per gestire una complessa logica di business, quindi giudicare i suoi meriti su un'app campione sviluppata nel corso di un fine settimana non ti espone al meglio che DDD ha da offrire. Vi esorto a continuare a guardare più in profondità nella DDD perché ho trovato che è uno strumento indispensabile, ma non dimenticate mai che è molto più di un linguaggio di pattern.

Answer 2

DDD non è realmente una lista di controllo, è una metodologia.

Oltre a Stefans risposta, suggerirei le seguenti (in ordine di importanza):

• lingua Ubiquitous - Il vostro codice di utilizzare gli stessi nomi/termini come azienda? I tuoi oggetti dominio utilizzano gli stessi nomi dell'azienda?
• Comportamento - è la maggior parte comportamento/logica associato direttamente con oggetti di dominio, o non si hanno un sacco di DTOs muti?
• Contesti con limiti - Avete chiaramente definito le aree di responsabilità e Separazione delle preoccupazioni?
• Aggregati - Avete identificato gli aggregati in base agli oggetti radice e le strategie di blocco per applicare gli invarianti di business?
• Repositories - E 'tutti i dati accesso/l'interrogazione avviene tramite repository, o avete il codice SQL in altre classi?
• Servizi di dominio - Avete Servizi di dominio per logica di business che non lo fa naturalmente in forma in un oggetto di dominio
• Specifiche - Avete le regole di business ben avvolto in specifiche?
• Specifiche query - Avete domande/filtri pre-inscatolati pre-inscatolati wrapper in Specifiche delle query?

Poi ci sono tutte le altre cose!

penso che la maggior parte professionisti DDD vorrebbe dire:

"Io lavoro con esperti del settore per capire le loro esigenze, e scrivono sistemi che (a) corrispondono i termini e processi imprese, (b) aiutare altri sviluppatori capire il dominio aziendale, e (c) può flettere per soddisfare i mutevoli requisiti aziendali "

Sperare che aiuti!