Vernon e Millett descrive diversi modelli di recupero dei dati per le esigenze di ui (reporting in generale).
Sebbene alcuni pro e contro di ogni approccio siano discussi, non ho potuto ottenere una solida comprensione su quale usare quando.
Considera le query ad hoc. Vernon li chiama Use Case Optimal Query , ma non dice troppo. Millett avverte solo di performance vs dry violation tradeoff . Alcuni blog ne parlano come il passo verso CQRS.
E tutto ciò sembra più una questione di preferenze personali piuttosto che una scelta ben fondata. E non appena la soggettività appare mentre discuti i conflitti di decisioni architettoniche si verificano.
Aggiornamento aggiungerei più dettagli, suppongo ...
Prefazione
Per prima cosa, non facciamo veramente DDD. Assolutamente. In nessun modo.
Usiamo (triste ma vero) TransactionScript con AnemicModels.
Sì, abbiamo un dominio complesso, in cui DDD non sarà eccessivo.
Ora ti sento dire: "DDD parla di schemi strategici!". Lo so, anche loro non sono con noi. =)
Tuttavia, tutti i modelli sono utili. se applicato ragionevolmente.
Nessuno proibisce di fare passi convergenti da entrambe le parti. Ho già sottolineato nei commenti che i modelli tattici preoccupano maggiormente la squadra e possono portare i dividendi relativamente velocemente.
Il caso
Nelle nostre regole aziendali utilizziamo estensivamente DTO che contengono tutti i dati sufficienti per eseguire l'elaborazione dei comandi. Tuttavia, utilizziamo gli stessi DTO per l'assemblaggio dei dati per UI / Reporting. Introduce un accoppiamento molto sgradevole. La pratica dimostra che questi DTO sono spesso piegati alle esigenze dell'interfaccia utente. Ma è l'interfaccia utente che cambia frequentemente per diverse iterazioni. Gli utenti capiscono che vorrebbero avere più dati strutturati e organizzati in modo diverso.
Contrariamente all'interfaccia utente, i comandi sono molto più stabili e quando la struttura del comando deve cambiare l'interfaccia utente viene quasi inevitabilmente modificata.
In questo modo l'interfaccia utente 'respirante' scuote 'gli strati utilizzati dalla logica aziendale che elabora i comandi. Spesso ci troviamo ad allineare le interfacce e a correggere i test non funzionanti.
Con tutto quanto detto sopra ho trovato ragionevole provare a separare le query dall'elaborazione dei comandi in funzionalità assolutamente nuove.
IBlaBlaQuery è l'esatta implementazione di Use Case Optimal Repository Query. Il cliente riceve dati di vista specifici + dati per i comandi di costruzione. È coperto con test di unità e integrazione. Il codice funziona, alcuni compagni di squadra come la soluzione.
Esistono ancora quelli che
- a) insistere sul principio VIOLAZIONE violata,
- b) lamentarsi di un nuovo design non abituale.
Probabilmente chiedi qui: "Perché non hai discusso di questo disegno prima di metterlo in vita?" E questo è il posto giusto per la mia domanda.
Continuano a difendere DRY, tu offri loro di affrontare i fatti e concordare sulla fragilità del design, dichiarano di non vederlo o non è un grosso problema come un approccio radicalmente nuovo. Altri sviluppatori preferiscono rimanere neutrali e non esprimere esplicitamente le proprie opinioni.
Cannot you give us unequivocal solid arguments? - Then we do not accept and even consider a trial of your design.
Dopo diverse iterazioni di questo tipo, ti basti ricordare i detti "La pratica è il criterio della verità" e "È meglio chiedere perdono che il permesso" e darle volontariamente una risposta diventare un asino . (Posso ammettere che lo sono davvero, ma semplicemente non me ne accorgo.)
Ecco perché cerco di evitare la soggettività e di chiedere criteri formali oggettivi.