Consapevolezza del repository DDD di altri repository

Question

È generalmente accettabile che un repository possa accedere a un altro repository? Specificamente in questo caso, ho una radice aggregata che utilizza un'altra radice aggregata per determinare quali entità aggiungere. Cade lungo le linee di una relazione Articolo/Articolo. La ragione per cui il Tipo di articolo è una radice aggregata è che sono mantenibili separatamente all'interno di uno strumento di gestione al di fuori dell'ambito di ogni singolo Articolo.

Se è importante, sto solo creando le istanze del repository attraverso un'implementazione di repository factory, quindi non lo sto creando direttamente dal nome concreto della classe. In nessun momento la conoscenza aggregata del repository.

Modifica - Maggiori informazioni:

L'implementazione specifica è che siamo in grado di allegare immagini a un documento. Non solo possiamo gestire le immagini sul documento, ma ci sono diversi tipi di immagini (i tipi sono definiti come il modo in cui è implementato, al contrario di un'estensione, per esempio). Il documento aggregato è uno dei pochi tipi di altri oggetti nel sistema che usano queste immagini e non tutti usano gli stessi tipi. Mentre leghiamo le regole nei servizi di dominio, questo è più specificamente orientato verso la costruzione del documento aggregato. Quando si costruisce l'aggregato, abbiamo cinque immagini di un tipo specifico e uno di due altri tipi. Li estrapiamo singolarmente perché sono memorizzati in elenchi separati nel complesso. La convalida non è il problema, ma limita il tipo di immagini che vengono valutate durante l'assemblaggio del documento.

Answer 1

Immagino che si riduce a quello che stai cercando di fare. Se si tratta di una sorta di passaggio di convalida (ad esempio, rimuovere tutti gli elementi con tipi di elemento scaduti) si potrebbe obiettare che appartiene a un livello di servizio oa una specifica. Dalla lingua che usi (cioè "determinare quali entità aggiungere") sembra suggerire quest'ultima, sebbene sia difficile da dire senza ulteriori dettagli.

Immagino che da un certo punto di vista non ci sia un vero motivo per cui non puoi (non sono affatto un super DDD purissimo), soprattutto dal momento che un oggetto e il suo tipo possono essere visualizzati come una radice aggregata ed è solo i dettagli di implementazione necessari per fornire una console di gestione che impedisca.

Da un altro punto di vista sembra suggerire che vi sia una sfocatura tra le radici aggregate che potrebbe suggerire che due diversi contesti sono all'opera. Ad esempio, si potrebbe sostenere che uno strumento di gestione forma un contesto limitato separato per l'applicazione principale e quindi il caso in cui il tipo di elemento è una radice aggregata in realtà non si applica. per esempio. Lo strumento di gestione potrebbe riguardare solo i tipi di oggetto (e mai gli articoli) mentre l'applicazione principale potrebbe visualizzare i tipi di oggetto come più di un oggetto valore di un'entità.

Aggiornamento

come si parla assemblare il documento questa sembra la responsabilità di una classe fabbrica che può assemblare correttamente un'entità valida (la fabbrica può utilizzare il tipo di archivio immagini). Un repository dovrebbe (ai miei occhi) mostrare le operazioni di query e aggiunta, non la logica per configurare le entità (eccetto forse reidratare dalla persistenza).