DDD: radici aggregate di sola visualizzazione, creazione di DTO e un problema di caricamento lento

Attenzione: ciò che viene dopo è una lista di affermazioni pericolose che chiamo la mia opinione .

Prima di tutto, comprendo i tuoi motivi per utilizzare le stesse classi per i tuoi aggregati e le tue entità ORM, ma è mio dovere dirti che così facendo, stai incrementando l'accoppiamento tra le tue politiche (dominio) e i tuoi dettagli (ORM , DB).

Ora proverò a rispondere alle tue domande:

My first question is - is it okay to have these view classes in the domain "layer" despite only being a different representation of the already created aggregate roots? Should I call them view models or are they true aggregate roots that are only used for reading?

Non ho tutte le informazioni, ma direi che, se questa classe "view" è usata solo quando l'utente sta facendo un'operazione di lettura (intendo una richiesta GET qui), allora questa classe è probabilmente solo una parte dei tuoi DTO. Se hai costantemente bisogno di questa classe in un'operazione di modifica, allora esaminerei il design, forse c'è un errore lì.

My second question is - when building DTOs without any additional business logic, is it okay to bypass creating a domain service and use a repository directly?

Ho visto in che modo le diverse organizzazioni applicano le due opzioni qui. Non sono preoccupato, ma ti suggerisco di separare i tuoi servizi che modificano lo stato dai servizi che sono appena utilizzati per rispondere a una query. Inoltre, se decidi di ignorare il servizio o meno, si prega di essere coerenti attraverso l'applicazione.

My third question is - in the domain layer, I don't know how the view classes will be used, thus I should not instruct repositories to fetch specific references eagerly. However, I need to do that to prevent the N+1 problem. What is the correct solution here?

Come sarebbe se separi i tuoi aggregati dalle tue entità ORM? Non so quale tecnologia stai usando, ma in quel caso penso che avresti bisogno di recuperare le entità con entusiasmo. Ecco perché uso per progettare i miei aggregati pensando in scala. Penso che nelle tue radici aggregate dovresti avere una lista di altre radici / entità aggregate solo se sai che il loro numero sarà veramente piccolo. Altrimenti, rimuoverei quell'elenco e aggiungerei il riferimento nell'altro lato della relazione.

Ci sono molti argomenti in questa discussione quindi per favore fatemi sapere se vi ho aiutato o cos'altro avete bisogno di sapere:)

Da quello che ho visto:

Il livello entità ha oggetti entità che poi trasferiscono in oggetti POCO (queste sono le classi del dominio) e poi in DTO per la presentazione.

Credo anche

so my aggregate roots are also my ORM entities

Non scalerà minimamente mentre stai già iniziando a vedere, quindi userei gli oggetti entità dedicati e li trasformerò automaticamente in oggetti vero dominio e poi opzionalmente in un DTO.