Violano eventuali principi di progettazione domini se i repository parlano tra loro durante la costruzione?design, repository ed entità miste gestite da domini
Esempio un repository di indirizzi utente comunica con gli archivi città/area geografica/paese per ottenere dati?
Violando Domain Driven Design, penso che i repository non dovrebbero fare riferimento l'uno all'altro. Inoltre, non dovresti mappare 1: 1 tra repository e tabella del database.
Questo è il concetto di Aggregate e AggregateRoot. Esempio, assumere in banca dati ha 2 tabelle:
Order
OrderLine
con rapporto 1: n, (Ordine, OrderLine) è definito come un aggregato perché OrderLine non può vivere da soli senza ordine. E in questo caso, Order è la radice di questo aggregato.
Con questo, invece di creare due repository:
OrderRepository
OrderLineRepository
Hai solo dovrebbe avere un solo OrderRepository di prendersi cura di tutto il complesso, con carico a cascata, inserire e cancellare con OrderLine
Quindi, in Nel tuo caso, dovresti considerare che hai repository di indirizzi/città/regioni/paesi esistenti o meno.
Spero che questo aiuto
Abbiamo incontrato lo stesso problema con le valute ISO e paesi ISO nel nostro sistema. Abbiamo rilevato che quasi tutte le root aggregate di cui disponevamo (e che hanno un repository corrispondente) richiedevano la valuta e/o le entità dei paesi come entità secondaria. Questo stava dimostrando inefficiente dal punto di vista di gestione dei dati e il recupero dei dati così abbiamo fatto la seguente:
dalla mia esperienza DDD e il libro blu è una guida preziosa, ma non dovete adottarlo 100% con precisione, tu prendi le raccomandazioni a bordo, ma poi lo adotti per dare un senso per te.
Spero che questo aiuti ...
Ci sono diversi approcci al problema:
mantenere un rapporto stretto tra le 2 radici di aggregazione e idratare in modo sistematico dell'intero aggregato della seconda radice quando si idratare la prima radice. Ciò richiede che il primo repository parli al secondo, che IMO non infrange alcun principio DDD ma può essere potenzialmente problematico in termini di prestazioni.
Collegare le 2 radici insieme senza stringere. Questo in pratica significa indicare l'ID radice di riferimento invece dell'istanza completa. O il codice client o il root stesso (anche se alcuni diranno che quest'ultimo è una cattiva pratica) reidratano la root referenziata dal suo ID chiamando il suo repository.
Realizza che oggetti come Città, Regione o Paese sono oggetti valore (immutabili), non hanno bisogno di un ID e possono essere referenziati direttamente da qualsiasi radice o entità aggregata senza ulteriori conseguenze. Questo significa anche nessun repository per questi oggetti.
Scegliere tra le opzioni 1 e 2 è solo una questione tecnica e influisce solo sulle prestazioni e sul comfort dello sviluppatore. L'opzione 3 è più una scelta di dominio con possibili impatti sul business. Le entità di dominio, città, regione e Paese, sono in grado di creare, modificare ed eliminare l'utente? Ci sono schermi speciali dedicati a quelli? Questi sono problemi che devi discutere con il tuo esperto di dominio prima di prendere una decisione.
Link vi possono essere utili:
Aggregate Root references other aggregate roots
http://tech.groups.yahoo.com/group/domaindrivendesign/message/8696
bene. L'intero scopo dei repository in DDD è di astrarre la fonte dei dati. Se il tuo indirizzo utente ha bisogno di città/regione/paese per essere completo, utilizza questi repository.
Il problema con questo approccio è che le query saranno piuttosto inefficienti.
Invece, crea una vista nel database che carica l'indirizzo utente con tutte le informazioni richieste (o usa il tuo ORM se ne hai uno).
In sintesi:
Non c'è nulla in DDD che determina come si dovrebbe implementare i repository. DDD è molto chiaro che l'entità caricata dal repository dovrebbe essere completa, non importa come le informazioni sono memorizzate nell'origine dati = Il repository è solo definito come un livello di astrazione
non aiutano salvo per la alcune cose sono state fatte nel mio sistema. Abbiamo province/stati e paesi normailizzati. Quindi, se un utente o un negozio ha bisogno di caricare i suoi dati di indirizzo e ha riferimenti alle tabelle che il repository di regione/nazione utilizzerebbe. Va bene caricare versioni diverse di regioni/paesi poiché in questo contesto li userò di più come oggetti valore rispetto alle entità? –
grazie per questa semplice spiegazione. finalmente la lampadina si accese per me. :) – kman