In che modo Domain Driven Design gestisce i report?

Question

Ho trovato DDD essere naturale se sto lavorando su un tipo operativo/transazionale di applicazione. Tuttavia, sono sempre bloccato in un modo ragionevole per gestire il tipo di segnalazione delle funzioni.

La segnalazione di cui sto parlando su non è tenuto a segnalare generazione, ma anche le funzioni che eseguono le query relativamente complesse. (ad esempio, fornire il riepilogo di tutti gli ordini effettuati da un operatore commerciale o visualizzare il riepilogo dell'account per gli account di trading con determinati stock, ecc.). Possono essere semplicemente alcune query o funzioni di supporto utilizzate insieme a quelle funzioni operative.

Per tali funzioni, è del tutto naturale, se siamo in grado di eseguire join in SQL (o qualunque linguaggio di query), ottenere le colonne che ci interessano, e restituire il set di risultati massaggiato. Tuttavia, sembra che non vada così bene con DDD: abbiamo bisogno di un repository speciale in più o di avere un repository più correlato che restituisca uno speciale "oggetto entità/valore" (che è il set di risultati specializzato). Questo tipo di "entità" speciali non ha infatti alcun significato di dominio.

Se si desidera utilizzare il livello di dominio significativo, questo potrebbe creare molte ricerche aggiuntive da repository diversi, oltre a un sacco di lavoro di aggregazione nel dominio o livello di servizio, che facilmente causerà un degrado delle prestazioni orribile.

Ho anche pensato di avere un altro "percorso" per questo tipo di funzione, che non passa attraverso il "percorso DDD", avendo il suo modo di ottenere i dati del report dal DB, comporre i risultati per la visualizzazione. Tuttavia renderà l'applicazione inutilmente complicata, e ancora peggio, abbiamo fornito un percorso extra in modo che gli sviluppatori che sono più abituati allo sviluppo tradizionale orientato al DB possano tendere a utilizzare questo percorso anche se non è appropriato.

ho pensato tale situazione è abbastanza comune (di solito un grande sistema non contiene operativo, ma anche la segnalazione e le funzioni di indagine), vorrei sapere come la gente ne occupa?

Answer 1

Recentemente abbiamo iniziato a utilizzare DDD per lo sviluppo del sistema. Avevo le stesse preoccupazioni del tuo, ma alla fine ho optato per Command Query Responsibility Segregation (CQRS) [Fowler, Young, Dahan]. Mentre è necessario "il percorso db" per l'interrogazione, non mi sembra affatto che si possa tentare di eseguire direttamente comandi DB per i comandi (quelli che alterano lo stato del dominio). La separazione è molto chiara: i comandi passano attraverso il dominio, le query passano direttamente al DB.

Answer 2

Un approccio potrebbe essere quello di avere un sistema di reporting separato che correva feed di dati da memorizzare i dati della tua applicazione per memorizzare un'altra copia dei dati in un formato più relazionale.

Una scorciatoia che ho usato è quello di creare una vista o stored procedure per restituire i dati uniti in un semplice oggetto muto.

Answer 3

query relativamente complicate. (ad esempio, fornire il riepilogo di tutti gli ordini effettuati da un operatore, o visualizzare il riepilogo dell'account per gli account di trading con determinati stock, ecc.)

È frequente che gli archivi eseguano tali attività. Penso che tu sia preoccupato di come implementarlo in modo efficiente, e la risposta è "caricamento pigro".

Ad esempio, prendiamo "il riepilogo di tutti gli ordini effettuati da un operatore". Il "sommario" è un'attività di segnalazione, quindi mettiamola da parte. L'attività del dominio è "trova tutti gli ordini per un commerciante". Si potrebbe avere un metodo di deposito come questo:

List<Order> findOrdersByTrader(Trader trader); 

è possibile implementare questa caricando solo le informazioni minimo indispensabile (sintesi) per ogni ordine. Se si inserisce l'interfaccia del repository nell'entità Order, l'entità stessa può richiamare il repository per caricare ulteriori sottoentità come e quando richiesto.

---

Aggiornamento: Il tuo commento rende il problema più chiaro - ho capito male la parte di aggregazione in precedenza. Sembra che il "riepilogo dell'ordine" appartenga realmente al tuo dominio. A volte non è ovvio che un concetto fa parte del dominio, ma se si tratta di una funzionalità di cui gli utenti parlano ("Voglio vedere un riepilogo degli ordini effettuati da questo trader") e non esiste un oggetto esistente che possa farlo , questo è un segno di un concetto nascosto nel tuo dominio. Dopotutto, hai bisogno di dell'oggetto per tenere traccia di "quanti ordini per ogni stock" e non c'è motivo per cui questo oggetto non possa far parte del tuo dominio.

Answer 4

In termini di DDD Reporting nella maggior parte dei casi è un Contesto Limitato separato e un sottodominio di supporto in cui la progettazione basata su domini sarebbe eccessiva. Ricorda il concetto più importante di DDD: concentra i tuoi sforzi di modellazione sul dominio principale e implementa tutto il resto utilizzando la soluzione più semplice possibile.