La seguente entità di dominio può contenere la logica per la creazione / eliminazione di altre entità?

a) DDD non specifica che gli oggetti dominio non devono creare oggetti dominio. Un oggetto dominio può benissimo creare un altro oggetto dominio. Un aggregato è responsabile dell'applicazione di un limite di coerenza attorno a un cluster di entità e oggetti valore. Come tale, potrebbe benissimo avere comportamenti che creano entità. Ad esempio, lo stereotipo dell'aggregazione dell'ordine di vendita può creare istanze di entità riga ordine (o oggetti valore, a seconda dell'implementazione). L'importante è assicurarsi che il dominio e le entità vengano creati o eliminati in luoghi ben definiti. Dai un'occhiata a questo articolo che valuta la creazione di aggregati in un modello di dominio.

b) La mappatura tra un'entità del mondo reale e l'astrazione corrispondente nel codice non è mai isomorfa. Le astrazioni nel codice sono vincolate da vincoli tecnici che non possono essere trascurati. Il codice non è inteso come un isomorfismo della realtà, è solo inteso esibire caratteristiche funzionali che soddisfano serie di requisiti. La somiglianza tra realtà e codice è un aspetto che ci sforziamo di semplificare il processo di sviluppo. In altre parole, se un'entità del mondo reale crea qualcosa, non si traduce immediatamente nella corrispondente astrazione nel codice, sebbene possa - non ci sia una regola difficile.

a) Un'entità di dominio può occasionalmente creare o eliminare altre entità. Tuttavia, in genere lo fa aggiungendo o rimuovendo da una delle sue raccolte interne se l'entità da aggiungere / rimuovere è una delle sue entità figlio dallo stesso aggregato (nel qual caso il tuo ORM molto probabilmente sarà in grado di tracciare le modifiche a la raccolta e la loro permanenza automatica) o chiamando un Repository se l'entità da creare / eliminare è una radice Aggregate. Difficilmente sembra appropriato che un oggetto dominio conosca l'unità di lavoro e lo stato corrente degli oggetti nella transazione utente - questo è un lavoro per il livello Applicazione.

Devi anche fare attenzione a non mettere troppo complessa la logica di creazione di oggetti in un'entità - assemblare oggetti complessi da varie parti piuttosto appartiene a una Fabbrica.

b) C'è un'eleganza davvero nel codice che rispecchia il modo in cui i concetti del mondo reale si sviluppano - è scorrevole, molto leggibile e facilmente comprensibile. Inoltre, è vero che DDD ci incoraggia a dare un nome ai nostri costrutti di codice dopo i concetti del mondo reale del dominio.

Tuttavia, ci dice anche che il modello e il linguaggio onnipresente dovrebbero essere il risultato di una collaborazione di esperti / sviluppatori di dominio. Non è che potresti semplicemente versare il dominio su una tastiera e guardare i tuoi oggetti di dominio scriversi magicamente. L'astrazione non è solo traduzione dal reale al codice, con i nomi che diventano classi e i verbi che diventano metodi, è più di questo. È necessario un qualche tipo di processo di trasformazione in cui le esigenze aziendali e le esigenze tecniche si incontrano. Durante quel processo, alcuni oggetti o relazioni tra oggetti che esistevano nel mondo reale saranno preservati, altri no - perché non sono convenientemente rappresentabili nel codice, o perché sconfiggono le buone pratiche del software come la separazione delle preoccupazioni, la coesione, il basso accoppiamento, ecc. Verranno visualizzati anche nuovi oggetti di dominio, forse quelli che non hanno una materializzazione nel dominio del mondo reale.

Quindi la versione computerizzata di un problema o un'attività del dominio reale è un animale diverso, non esiste una regola che ti consenta di dire in anticipo se ci sarà una classe per questo attore o un metodo per quel concetto di business. Tutto quello che puoi essere sicuro è che i loro nomi verranno probabilmente trovati da qualche parte nel codice.