DDD non è appropriato per il mio sito web o dovrei introdurre un livello di query?

Dopo aver letto il libro di Evans, vedrai che DDD è una raccolta di concetti. Il libro è stato scritto oltre un decennio fa. La mia opinione oggi è che ha parti buone, ma è facilmente frainteso e talvolta usato impropriamente. In realtà, alcune parti potrebbero non essere necessarie o potrebbero non essere adatte alla tua applicazione o agli strumenti scelti.

Per quanto riguarda EF, non penso che il concetto DDD di combinare dati e comportamenti nelle tue entità si fonda bene con esso. I modelli di entità EF devono essere privi di comportamento se si desidera evitare un sacco di errori imprevisti e colli di bottiglia nelle prestazioni. Come indicato in altre risposte, usare un pattern CQ (R) S è un buon modo per implementare il comportamento esternamente dalle entità EF. In conclusione, cerca di evitare di implementare un "modello di dominio ricco" usando metodi su entità EF. Puoi ancora scricchiolare la conoscenza del business in "il modello", ma il tuo "modello" dovrebbe contenere classi diverse per dati (entità) e comportamento (operazioni).

Inoltre non mi piace l'idea di repository, ma questa è principalmente la mia opinione e sono sicuro che gli altri non saranno d'accordo quando dico che non sono davvero necessari quando si utilizza un ORM come EF. Forse un decennio fa, prima che avessimo i generici moderni, erano più utili. In questi giorni, puoi racchiudere una singola interfaccia generica attorno a un DbContext EF e disporre di un singolo repository generico (insieme all'unità di lavoro).

D'altra parte, cose come la lingua onnipresente, le radici aggregate, i contesti limitati, i criteri di query, ecc. Io considero le perle. Mantenere il livello dell'applicazione sottile è anche una buona pratica senza tempo. Sembra che l'altro sviluppatore potrebbe non aver applicato i concetti DDD appropriati e, come già detto da qualcun altro, ha creato più problemi di quanti ne abbiano risolti.

1) Non lo direi. Il DDD è utile per i sistemi complessi (il che può significare qualcosa di più sofisticato del CRUD). La logica del dominio può essere molto complessa indipendentemente dalla sua condivisione nel sistema rispetto alla logica della query.

2) Vedo due modi per affrontare questo. Uno è limite di dimensioni aggregate. I piccoli aggregati sono meno inclini a un carico di dati eccessivo e lento. L'altro è separato le tue letture dalle tue scritture (CQRS). Questo è fondamentalmente il "Servizio di query" che stai citando, ma è meglio che restituisca oggetti modello letti separati che non siano le tue entità.

3) Chiamando l'entità pigra che carica un codice l'odore è in qualche modo ... supponente. Potrebbe effettivamente essere una soluzione. Tuttavia, potresti avere ancora problemi di prestazioni, come aggiungere un'entità a un'enorme raccolta che ti obbliga a caricare l'intera raccolta. Un design di aggregazione migliore può risolverlo.

Ho costruito diversi modelli DDD, la persistenza è stata gestita da NHibernate. Siamo andati con uno schema di deposito nei nostri primi progetti e abbiamo costruito tutte le nostre query nei nostri repository.

Questa è una grande idea in teoria, ma quello che abbiamo imparato in pratica è che si finisce per scrivere un sacco di posti nella caldaia quando si implementano i repository ed inoltre erano praticamente inutili comunque. Oltre al metodo standard save, delete e FindByID, tutte le query effettive che vengono utilizzate sono quasi sempre univoche per un particolare caso d'uso, specialmente quando si prendono in considerazione le proprietà che si desidera caricare.

Quindi utilizziamo ancora un modello di repository ma abbiamo solo metodi save, delete, findByID e findByQuery. La query è incapsulata in un oggetto e passata nel repository, l'oggetto query è costruito nel livello applicazione.

Se il codice è ciò con cui stai lottando, trova la ragione per cui è lì. Se non ci sono ragioni valide per essere trovato, sbarazzarsi del codice e scrivere il codice che ha un motivo per essere lì. La tua domanda sta mostrando un elenco di problemi autoinflitti causati dall'uso di un pattern che potrebbe aver risolto un paio di problemi, ma ha introdotto molto di più, molti dei quali tecnici.

Consentitemi di fare riferimento alla mia risposta su SO se DDD sia o meno una perdita di tempo: link

Questo potrebbe darti un po 'di prospettiva su cosa sia il DDD e cosa non lo sia. Il TL; DR è che non è una soluzione tecnica ma potrebbe (non sarebbe!) Finire in una soluzione tecnica di qualche tipo, ma non è necessario.

L'estenuante recupero del grafico potrebbe suggerire un problema di SELECT N + 1 attraverso il caricamento lazy o i loop che prelevano il codice degli elementi correlati. Questo potrebbe essere fatto per essere in grado di produrre una proiezione sui dati in memoria. Tuttavia, osservando lo snippet di classe, non vedo un'influenza DDD profonda lì, poiché altrimenti le collezioni non sarebbero state lì.

Potrebbe essere saggio vedere se è effettivamente necessario recuperare istanze di entità in un grafico, poiché potrebbe essere più rapido formulare la proiezione dei dati necessari come query di linq sulle entità nel modello e lasciare che DB fa la produzione stabilita. Il set di risultati può quindi essere recuperato in nuovi oggetti POCO, che sono semplicemente elenchi semplici e vengono quindi utilizzati nell'interfaccia utente. Ovviamente si tratta di dati letti / solo, ma per molti casi questo è sufficiente.