What is the benefit of doing this?
Una cosa da tenere a mente è che l'applicazione, il modello di dominio e la persistenza evolvono ciascuno a un ritmo diverso dagli altri. Si prevede che il dominio sia in grado di supportare più applicazioni; e dovresti essere in grado di revisionare frequentemente l'implementazione all'interno del dominio, ma la persistenza generalmente si evolve più lentamente, perché non eliminiamo lo stato accumulato ogni volta che aggiorniamo il modello.
The Repository interfaces were contained in the Core project and the Repository classes (implementations) were contained in the Infrastructure project.
Bene, l'interfaccia del repository è il contratto che definisce l'accordo tra l'applicazione e il modello di dominio (che è esso stesso che incapsula il componente di persistenza dietro di esso). Quindi ha un certo senso che quelle interfacce siano nel core o nell'applicazione - se non le si estraggono separatamente, e ci si aspetta di supportare più applicazioni, il core è la casa naturale per loro. / p>
Per quanto riguarda dove vanno le implementazioni, questo diventa un po 'più complicato. Le entità e i valori nel tuo modello di dominio hanno due rappresentazioni logicamente distinte: quella che vedi in memoria e quella che vedi nel tuo negozio durevole (pensa gli oggetti in memoria rispetto alle righe in un RDBMS).
Quello che Evans ha descritto nel libro blu è che il ruolo del repository è quello di fornire l'illusione che gli aggregati vivano tutti nella memoria. Quindi è ragionevole pensare al repository come un'interfaccia del fornitore di servizi, con il componente dell'infrastruttura come fornitore di servizi responsabile della decisione su come serializzare / deserializzare i dati verso / dal libro del record.
CQRS aiuta a rendere chiara questa separazione; poiché i casi di utilizzo di lettura e scrittura differiscono, anche i ruoli definiti per il repository sono diversi. In particolare, non sorprende che potremmo decidere che un particolare caso d'uso vuole un tipo specifico di archivio dati: un archivio documenti per fornire rappresentazioni memorizzate nella cache di viste o un database grafico per query veloci di un social network.
In questo tipo di design, questa modifica è semplice: basta scambiare l'implementazione di persistenza specifica e le modifiche alle applicazioni e ai modelli di dominio sono minime; l'infrastruttura cambia molto (sostituzione completa all'interno di tale caso d'uso) e la composizione di root un po '(sostituendo un modulo di persistenza con un altro), ma il modello e l'applicazione non sono interessati dalla modifica.
Naturalmente, può essere più complicato: nei sistemi basati su eventi, di solito hai una rappresentazione degli eventi nel tuo archivio di eventi durevoli, che può o meno allinearsi con la rappresentazione di eventi in memoria, che a loro volta sono distinti dalle rappresentazioni degli aggregati che si utilizzano quando si calcolano nuovi eventi. In questo tipo di sistema, la componente di persistenza normalmente riguarderebbe la scrittura di eventi da e verso l'archivio eventi, in cui le traduzioni delle cronologie degli eventi da e verso gli aggregati vivrebbero nel modello di dominio (es .: core).