Best practice o modelli di progettazione per il recupero di dati per report e dashboard in un'applicazione ricca di dominio

In primo luogo, voglio dire che questa sembra essere una domanda / area trascurata, quindi se questa domanda necessita di miglioramenti, aiutami a renderla una grande domanda che può essere di beneficio agli altri! Sto cercando consigli e aiuto da persone che hanno implementato soluzioni che risolvono questo problema, non solo idee da provare.

Nella mia esperienza, ci sono due lati di un'applicazione: il lato "task", che è in gran parte guidato dal dominio ed è il punto in cui gli utenti interagiscono pienamente con il modello di dominio (il "motore" dell'applicazione) e il lato di reporting, in cui gli utenti ottenere dati in base a ciò che accade sul lato attività.

Dal lato delle attività, è chiaro che un'applicazione con un modello di dominio avanzato dovrebbe avere una logica aziendale nel modello di dominio e il database dovrebbe essere utilizzato principalmente per la persistenza. Separazione delle preoccupazioni, ogni libro è scritto al riguardo, sappiamo cosa fare, fantastico.

E il lato dei rapporti? I data warehouse sono accettabili o hanno una progettazione errata perché incorporano la logica aziendale nel database e i dati stessi? Per aggregare i dati dal database in dati del data warehouse, è necessario aver applicato la logica aziendale e le regole ai dati e che la logica e le regole non provenissero dal modello del dominio, provenivano dai processi di aggregazione dei dati. È sbagliato?

Lavoro su grandi applicazioni finanziarie e di project management in cui la logica di business è estesa. Quando riferisco su questi dati, avrò spesso MOLTE aggregazioni da fare per estrarre le informazioni richieste per il report / dashboard e le aggregazioni hanno molta logica aziendale in esse. Per motivi di prestazioni, l'ho fatto con tabelle altamente aggregate e stored procedure.

Ad esempio, supponiamo che sia necessario un report / dashboard per mostrare un elenco di progetti attivi (immagina 10.000 progetti). Ogni progetto avrà bisogno di una serie di metriche mostrate con esso, ad esempio:

1. budget totale
2. sforzo fino ad oggi
3. velocità di combustione
4. data di esaurimento del budget alla frequenza di combustione corrente
5. eccetera.

Ognuno di questi comporta molta logica di business. E non sto solo parlando di moltiplicare numeri o qualche semplice logica. Sto parlando per ottenere il budget, è necessario applicare una scheda con 500 tariffe diverse, una per il tempo di ciascun dipendente (su alcuni progetti, altre hanno un moltiplicatore), l'applicazione delle spese e l'eventuale markup appropriato, ecc. la logica è ampia. Ci sono voluti un sacco di aggregazione e ottimizzazione delle query per ottenere questi dati in un ragionevole lasso di tempo per il client.

Questo dovrebbe essere eseguito prima nel dominio? E le prestazioni? Anche con semplici query SQL, riesco a malapena a ottenere questi dati abbastanza velocemente da consentire al client di essere visualizzato in un tempo ragionevole. Non riesco a immaginare di provare a ottenere questi dati al client abbastanza velocemente se sto reidratando tutti questi oggetti di dominio, mescolando, abbinando e aggregando i loro dati nel livello dell'applicazione o cercando di aggregare i dati nell'applicazione.

Sembra in questi casi che SQL sia bravo a sgranocchiare i dati e perché non usarli? Ma poi hai una logica aziendale al di fuori del tuo modello di dominio. Qualsiasi modifica alla logica aziendale dovrà essere modificata nel modello di dominio e negli schemi di aggregazione dei rapporti.

Sono davvero a corto di come progettare la parte di reporting / dashboard di qualsiasi applicazione rispetto alla progettazione guidata dal dominio e alle buone pratiche.

Ho aggiunto il tag MVC perché MVC è il design du jour e lo sto usando nel mio progetto attuale, ma non riesco a capire come i dati di reporting si adattano a questo tipo di applicazione.

Sto cercando aiuto in questo settore: libri, schemi di progettazione, parole chiave per google, articoli, qualsiasi cosa. Non riesco a trovare alcuna informazione su questo argomento.

MODIFICA E UN ALTRO ESEMPIO

Un altro esempio perfetto che ho incontrato oggi. Il cliente desidera un rapporto per il team di vendita del cliente. Vogliono quella che sembra una semplice metrica:

Per ogni addetto alle vendite, quali sono le loro vendite annuali fino ad oggi?

Ma è complicato. Ogni addetto alle vendite ha partecipato a molteplici opportunità di vendita. Alcuni hanno vinto, altri no. In ogni opportunità di vendita, ci sono più addetti alle vendite a cui viene assegnata una percentuale di credito per la vendita in base al ruolo e alla partecipazione. Quindi ora immagina di passare attraverso il dominio per questo ... la quantità di reidratazione degli oggetti che dovresti fare per estrarre questi dati dal database per ogni addetto alle vendite:

Ottieni tutti i SalesPeople->
Per ognuno ottieni i loro SalesOpportunities->
Per ognuno ottieni la loro percentuale della vendita e calcola il loro importo delle vendite,
quindi aggiungi tutto il loro SalesOpportunityimporto delle vendite.

E questa è UNA metrica. Oppure puoi scrivere una query SQL che può farlo in modo rapido ed efficiente e ottimizzarla per essere veloce.

EDIT 2 - Pattern CQRS

Ho letto del modello CQRS e, sebbene intrigante, anche Martin Fowler afferma che non è stato testato. Come è stato risolto questo problema in passato. Questo deve essere stato affrontato da tutti in un punto o nell'altro. Qual è un approccio consolidato o logoro con una storia di successi?

Modifica 3 - Strumenti / sistemi di segnalazione

Un'altra cosa da considerare in questo contesto sono gli strumenti di reporting. Reporting Services / Crystal Reports, Analysis Services e Cognoscenti, ecc. Tutti si aspettano dati da SQL / database. Dubito che i tuoi dati verranno esaminati in seguito in futuro. Eppure loro e altri come loro sono una parte vitale del reporting in molti sistemi di grandi dimensioni. In che modo i dati per questi vengono gestiti correttamente laddove esiste persino una logica aziendale nell'origine dati per questi sistemi e, eventualmente, nei report stessi?

Questa è una risposta molto debole, ma arriva direttamente al nocciolo della questione:

In termini di DDD forse pensi di riferire come un contesto limitato? Quindi, piuttosto che pensare in termini di "IL" modello di dominio, dovresti essere disposto a pensare che sia giusto avere più di un modello. Quindi sì, va bene se il dominio di reporting ha una logica aziendale di reporting, così come va bene per il dominio di transazione avere una logica di business transazionale in esso.

Per quanto riguarda la domanda di, diciamo SQL stored procedure vs. modello di dominio nel codice dell'applicazione, gli stessi pro e contro valgono per il sistema di reportistica come per il sistema transazionale.

Dal momento che vedo che hai aggiunto una generosità alla domanda, ho letto di nuovo la domanda e ho notato che stai chiedendo risorse specifiche su questo, quindi ho pensato di iniziare con il suggerire di esaminare altre domande Stack Overflow sull'argomento, e ho trovato questo https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

L'essenza generale di quello è usare CQRS come modello per il tuo sistema, che è coerente con DDD, e fare affidamento sulle responsabilità del lato query come un modo per fare report, ma non sono sicuro che sia una risposta utile in il tuo caso.

Ho anche trovato questo http://www.martinfowler.com/bliki/ReportingDatabase.html , che ho trovato collegato da qui: http://groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261

Ecco un interessante articolo di ACM sull'argomento: http://dl.acm.org/citation.cfm?id=2064685 ma è dietro un paywall, quindi non posso davvero leggerlo (non un membro ACM :().

C'è anche questa risposta qui su una domanda simile: https://stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database

e questo: http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

Spero che sia di aiuto!

La mia comprensione dalla tua domanda è questa: ha un'applicazione per attività quotidiana

Visualizza >> Controller >> Modello (BL) >> Database (Dati)

Domanda a scopo di segnalazione

Visualizza >> Controller >> Modello >> Database (Dati + BL)

Pertanto, la modifica del BL per " applicazione attività " comporterà anche la modifica del BL " reporting ". Questo è il tuo vero problema, giusto? Bene, va bene fare i cambiamenti due volte, quel dolore che devi prendere comunque. Il motivo è che entrambi i BL sono separati dalle rispettive preoccupazioni. Uno è per il recupero dei dati e uno per l'aggregazione dei dati. Inoltre, il tuo BL originale e il BL accresciuto verranno scritti in una tecnologia o un linguaggio diversi ( C # / java e proc SQL ). Non c'è scampo ad esso.

Facciamo un altro esempio non correlato specificamente alla segnalazione. Supponiamo che una società XXX segua le e-mail di tutti gli utenti per l'interpretazione e venda tali informazioni alle società di marketing. Ora avrà un BL per l'interpretazione e un BL per i dati aggregati per le società di marketing. Le preoccupazioni sono diverse per entrambi i BL. Domani se il loro BL cambia in modo tale che le mail provenienti da Cuba debbano essere ignorate, allora la logica aziendale verrà modificata da entrambe le parti.

Il reporting è un contesto limitato, o un sottodominio, per parlare liberamente. Risolve una necessità aziendale di raccogliere / aggregare i dati e di elaborarli per acquisire business intelligence.

Il modo in cui implementerai questo sottodominio sarà probabilmente un equilibrio tra il modo (più) architettonicamente corretto in cui puoi farlo e ciò che la tua infrastruttura consentirà. Mi piace iniziare dalla prima parte e spostarmi verso la seconda solo se necessario.

Probabilmente puoi dividerlo in due problemi principali che stai risolvendo:

1. Aggregazione o archiviazione dei dati. Ciò dovrebbe elaborare alcune origini dati e combinare le informazioni in modo tale che siano archiviate in un'altra origine dati.

2. Interrogazione dell'origine dati aggregata per fornire business intelligence.

Nessuno di questi problemi fa riferimento a uno specifico database o motore di archiviazione. Il tuo livello di dominio dovrebbe occuparsi solo di interfacce, implementate nel tuo livello di infrastruttura da vari adattatori di archiviazione.

È possibile che vengano eseguiti vari lavoratori o alcuni lavori pianificati, suddivisi in alcune parti mobili:

• Qualcosa da interrogare
• Qualcosa da aggregare
• Qualcosa da conservare

Spero che tu possa vedere alcuni dei CQRS brillare da lì.

Per quanto riguarda i rapporti, dovrebbe essere necessario solo eseguire query, ma mai direttamente nel database. Passa attraverso le tue interfacce e attraverso il tuo livello di dominio qui. Questo non è lo stesso dominio problematico delle tue attività principali, ma qui dovrebbe esserci ancora qualche logica a cui vuoi aderire.

Non appena ci si immerge direttamente nel database, si dipende maggiormente da esso e potrebbe eventualmente interferire con le esigenze dei dati dell'applicazione originale.

Inoltre, almeno per me, preferisco sicuramente scrivere test e sviluppare in codice piuttosto che query o stored procedure. Mi piace anche non bloccarmi in strumenti specifici fino a quando non è assolutamente necessario.

È tipico separare gli archivi di dati operativi / transazionali dal reporting. Quest'ultimo potrebbe avere dei requisiti per conservare i dati per motivi legali (es. Sette anni di dati finanziari per il controllo finanziario) e non si desidera tutto ciò nel proprio archivio di dati transazionali.

Quindi partizionerai i tuoi dati transazionali in base a una misura temporale (settimanale, mensile, trimestrale, annuale) e trasferirai le partizioni più vecchie nel tuo archivio di dati di report / cronologia tramite ETL. Può essere o meno un data warehouse con uno schema a stelle e dimensioni. Utilizzeresti strumenti di reporting di data warehousing per eseguire query e roll up e lavori batch ad hoc per generare report periodici.

Non consiglierei la segnalazione contro il tuo archivio di dati transazionali.

Se preferisci continuare, ecco altri pensieri:

1. "Best" è soggettivo e ciò che funziona.
2. Comprerei un prodotto di segnalazione piuttosto che scriverlo da solo.
3. Se stai usando un database relazionale, allora SQL è l'unico gioco in città.
4. Le procedure memorizzate dipendono dalla capacità di scriverle.

Software di gestione del progetto che usi in casa? Comprerei prima di costruire. Qualcosa come Rally e Microsoft Project.

Prima di tutto un po 'di terminologia, ciò che chiamate lato attività è noto come Transazionale e il lato Reporting è Analytics.

Hai già menzionato CQRS che è un ottimo approccio, ma l'applicazione pratica dell'approccio è poco documentata.

Ciò che è stato pesantemente testato è l'integrazione dell'elaborazione transazionale con un motore di elaborazione analitica. Questo viene talvolta definito Data Warehousing o Data Cubes. Il più grande problema per quanto riguarda l'analisi è che il tentativo di eseguire query sui dati transazionali in tempo reale è nella migliore delle ipotesi inefficace perché è davvero possibile solo ottimizzare un database per la lettura o la scrittura. Per le transazioni, si desidera elevate velocità di scrittura per evitare ritardi nell'elaborazione / esecuzione delle cose. Per i report, si desidera un'elevata velocità di lettura in modo da poter prendere decisioni.

Come rendere conto di questi problemi? L'approccio più semplice da comprendere consiste nell'utilizzare uno schema appiattito per i report e ETL (estrarre il carico di trasformazione) per trasferire i dati dallo schema transazionale normalizzato allo schema analitico denormalizzato. L'ETL viene eseguito regolarmente da un agente e precarica la tabella di analisi in modo che sia pronto per una lettura rapida dal motore di report.

Un ottimo libro per informarsi sul data warehousing è il Data Warehouse Toolkit di Ralph Kimball. Per un approccio più pratico. Scarica la versione di prova di SQL Server e raccogli il toolkit di Microsoft Data Warehouse che prende la discussione generale del primo libro ma mostra come applicare i concetti utilizzando SQL Server.

Esistono diversi libri collegati da quelle pagine che forniscono maggiori dettagli su ETL, Star Schema Design, BI, Dashboard e altri argomenti per aiutarti ad andare avanti.

Il modo più veloce per arrivare da dove sei a dove vuoi essere è assumere un esperto di BI e metterlo in ombra mentre implementa ciò di cui hai bisogno.

Il recupero di grandi quantità di informazioni su reti geografiche estese, compresa Internet, è problematico a causa di problemi derivanti dalla latenza della risposta, dalla mancanza di accesso diretto alla memoria delle risorse che servono i dati e dalla tolleranza agli errori.

Questa domanda descrive un modello di progettazione per risolvere i problemi di gestione dei risultati delle query che restituiscono grandi quantità di dati. In genere, queste query vengono eseguite da un processo client attraverso una vasta area (o Internet), con uno o più livelli intermedi, a un database relazionale residente su un server remoto.

La soluzione prevede l'implementazione di una combinazione di strategie di recupero dei dati, incluso l'uso di iteratori per attraversare set di dati e fornire un livello adeguato di astrazione al client, doppio buffering di sottoinsiemi di dati, recupero di dati multi-thread e suddivisione delle query.

E il lato dei rapporti? I data warehouse sono accettabili o hanno una progettazione errata perché incorporano la logica aziendale nel database e i dati stessi?

Non penso che tu stia parlando di logica aziendale, questa è più logica di reporting. Cosa fanno gli utenti con le informazioni su questa schermata, è semplicemente per gli aggiornamenti di stato? Il modello di dominio viene utilizzato per modellare le operazioni transazionali, la segnalazione è una preoccupazione diversa. Estrarre i dati da SQL Server o metterli in un data warehouse va bene per la creazione di scenari di report.

Il tuo modello di dominio dovrebbe imporre agli invarianti del tuo dominio, ad esempio un membro del progetto, che non può prenotare contemporaneamente allo stesso progetto o può prenotare solo x numero di ore alla settimana. Oppure non è possibile prenotare per questo progetto poiché è completo, ecc. Ecc. Lo stato del modello di dominio (i dati) può essere copiato per la segnalazione separatamente.

Per migliorare le prestazioni della query è possibile utilizzare una vista materializzata. Quando un'operazione viene commessa contro il tuo modello (ad es. Prenota 4 ore del tempo di questa persona per proiettare x) e ha esito positivo, può generare un evento che puoi quindi archiviare in un database di report ed eseguire i calcoli necessari per il tuo report. Sarà quindi molto veloce interrogarlo.

Tieni separati i contesti delle transazioni e dei rapporti, è stato creato un database relazionale per segnalare un modello di dominio che non lo era.

MODIFICARE

Post di blog utili sull'argomento http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html

Sono trascorsi 4 anni e ho trovato di nuovo questa domanda e ho la risposta per me.

A seconda dell'applicazione e delle esigenze specifiche, il database del dominio / delle transazioni e i report possono essere "sistemi" o "motori" separati oppure possono essere gestiti da un sistema. Dovrebbero, tuttavia, essere logicamente separati, il che significa che usano diversi mezzi per recuperare e fornire dati all'interfaccia utente.

Preferisco che siano fisicamente separati (oltre ad essere logicamente separati), ma molte volte li inizi insieme (fisicamente) e poi, man mano che l'applicazione matura, li separi.

Ad ogni modo, di nuovo, dovrebbero essere logicamente diversi. Va bene duplicare la logica aziendale nel sistema di reporting. L'importante è che il sistema di reporting ottenga la stessa risposta del sistema di dominio, ma è probabile che ci arrivi con mezzi diversi. Ad esempio, il tuo sistema di dominio avrà un sacco di regole aziendali molto rigide implementate nel codice procedurale (probabilmente). Il sistema di reportistica potrebbe implementare le stesse regole quando legge i dati, ma lo farebbe tramite codice basato su SET (es. SQL).

Ecco come potrebbe apparire realisticamente un'evoluzione dell'architettura della tua applicazione mentre si evolve:

Livello 1: domini e sistemi di report logicamente separati, ma sempre nella stessa base di codice e database

Livello 2 - Dominio logicamente separato e sistemi di reporting, ma separa i database ora, con la sincronizzazione.

Livello 3: domini e sistemi di reporting separati logicamente e fisicamente e database separati con sincronizzazione.

L'idea principale è che il reporting e il dominio abbiano esigenze radicalmente diverse. Profili di dati diversi (letture vs scritture e frequenza degli aggiornamenti), requisiti di prestazioni diversi, ecc. Pertanto devono essere implementati in modo diverso e ciò richiede una duplicazione della logica aziendale.

Spetta alla tua azienda escogitare un modo per mantenere aggiornate la logica aziendale del dominio e dei sistemi di reporting.

report / dashboard è necessario per mostrare un elenco di progetti attivi

Lo stato di ciascun progetto deve essere archiviato come informazione statica, calcolata e ben formattata nel database e qualsiasi simulazione deve essere gestita sul client come WebApp.

data di esaurimento del budget alla frequenza di combustione corrente

questo tipo di proiezione non dovrebbe essere eseguito su richiesta. La gestione di queste informazioni su richiesta, come l'esecuzione di calcoli su risorse, tariffe, attività, pietre miliari, ecc., Comporterà un ampio uso del livello di calcolo senza alcun riutilizzo di questi risultati per chiamate future.

Immaginando un ambiente distribuito ( cloud privato o pubblico ), otterrai enormi costi nel livello di calcolo, basso utilizzo del database e totale mancanza di cache.

Questo dovrebbe essere eseguito prima nel dominio? E le prestazioni?

La progettazione del software dovrebbe includere la capacità di eseguire la normalizzazione dei calcoli necessari per ottenere il risultato richiesto durante "l'immissione dei dati", non durante la lettura. Questo approccio riduce notevolmente l'utilizzo delle risorse informatiche e soprattutto crea tabelle che possono essere considerate "di sola lettura" dal cliente. Questo è il primo passo per creare un meccanismo di memorizzazione nella cache solido e semplice.

Quindi una ricerca prima, prima di completare l'architettura del software, potrebbe essere Distributed Cache System .

(richiesta: aggregazione)! = 1: 1

La mia considerazione è quindi (sia per il primo che per il secondo esempio), cercare di capire quando è corretto normalizzare i dati, avendo come obiettivo ridurre le aggregazioni per richieste del cliente. Che non può essere 1: 1 (richiesta: aggregazione) se un obiettivo è ottenere un sistema sostenibile.

Distribuire il calcolo sul client

Un'altra domanda, prima di terminare la progettazione del software, potrebbe essere, quanta normalizzazione, vogliamo delegare il browser del client?

Si chiamava MV *, è vero che è di moda oggi, oltre a questo, uno dei suoi scopi è quello di creare WebApp (app a pagina singola), che può essere considerato il presente di molte applicazioni complesse (e fortunatamente per le fatture che paghiamo al fornitore del cloud, questi vengono eseguiti nel client).

La mia conclusione è quindi di:

1. Comprendere quante operazioni sono realmente necessarie per eseguire la presentazione dei dati;

2. Analizzare quanti di questi possono essere fatti in background (e quindi distribuiti attraverso un sistema cache, dopo la loro normalizzazione);

3. Comprendere quante operazioni possono essere eseguite nel client, ottenere la configurazione dei progetti, eseguirla su Views sulla WebApp e quindi ridurre il calcolo eseguito in back-end;

Usa la cache per le query, usa il dominio per la memorizzazione nella cache.

C'è una funzione chiamata "top utenti" su StackOverflow. È possibile trovare una riga nella parte inferiore della pagina degli utenti principali, che dice "Solo domande e risposte non appartenenti alla community sono incluse in questi totali ( aggiornati quotidianamente )". Questo indica che i dati sono memorizzati nella cache.

Ma perché?

Per problemi di prestazioni forse. Forse hanno la stessa preoccupazione con la perdita della logica del dominio ("In questo caso sono incluse solo domande e risposte non-wiki della community").

Come?

Non so davvero come abbiano fatto, quindi ecco solo un'ipotesi :)

Innanzitutto, dobbiamo trovare domande / risposte target. Un'attività di pianificazione potrebbe funzionare, basta recuperare tutti i potenziali target.

In secondo luogo, esaminiamo solo una domanda / risposta. È un wiki non comunitario? Entro 30 giorni? È abbastanza facile rispondere con i modelli di dominio. Contare i voti e memorizzarli nella cache, se soddisfatti.

Ora abbiamo la cache, sono l'output delle derivazioni del dominio. La query è semplice e veloce perché esistono solo criteri semplici da applicare.

Cosa succede se i risultati devono essere più "in tempo reale"?

Gli eventi possono aiutare. Invece di attivare la memorizzazione nella cache con un'attività di pianificazione, è possibile suddividere il processo in molti sottoprocessi. Ad esempio, quando qualcuno vota sulla risposta dell'ippopotamo, pubblichiamo un evento che avvia l'aggiornamento della cache degli utenti principali dell'ippopotamo. In questo caso, potremmo vedere frequenti piccoli compiti rapidi.

Il CQRS è necessario?

Né con l'approccio delle attività di pianificazione né con l'approccio degli eventi. Ma i cqrs hanno un vantaggio. La cache è in genere altamente orientata alla visualizzazione, se all'inizio alcuni elementi non sono richiesti, potremmo non calcolarli e memorizzarli nella cache. CQRS con sourcing di eventi consente di riconsegnare la cache per i dati storici riproducendo gli eventi.

Alcune domande correlate:
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use -rich-domain-con-massicci-operazioni / 19416703 # 19416703

Spero che sia d'aiuto :)

Disclaimer:
sono abbastanza inesperto nelle applicazioni con modelli di dominio.
Comprendo tutti i concetti e ho già riflettuto a lungo su come applicare questi concetti alle applicazioni su cui sto lavorando (che SONO ricchi di dominio, ma mancano OO, modelli di dominio reali ecc . ) .
Questa domanda è anche uno dei problemi chiave che ho dovuto affrontare. Ho un'idea su come risolverlo, ma come ho appena detto ... è solo un'idea che mi è venuta in mente.
Non l'ho ancora implementato in un progetto reale, ma non vedo un motivo per cui non dovrebbe funzionare, però.

Ora che l'ho chiarito, ecco cosa mi è venuto in mente: userò il tuo primo esempio (le metriche del progetto) per spiegare:

Quando qualcuno modifica un progetto, lo stai caricando e salvando comunque tramite il tuo modello di dominio.
In questo momento, si dispone di tutte le informazioni caricate per calcolare tutte le metriche (budget totale, sforzo per data, ecc) per questo progetto.

È possibile calcolarlo nel modello di dominio e salvarlo nel database con il resto del modello di dominio.
Quindi la Projectclasse nel tuo modello di dominio avrà alcune proprietà come TotalBudget, EffortToDateecc., E ci saranno anche colonne con quei nomi nelle tabelle del database in cui è archiviato il tuo modello di dominio (nelle stesse tabelle o in una tabella separata ... non importa) .

Naturalmente, è necessario eseguire una sola volta per calcolare il valore per tutti i progetti esistenti mentre si inizia con questo. Tuttavia, i dati vengono automaticamente aggiornati con i valori calcolati correnti ogni volta che un progetto viene modificato tramite il modello di dominio.

Quindi ogni volta che hai bisogno di un rapporto gentile, tutti i dati richiesti sono già lì (pre-calcolati) e puoi semplicemente fare qualcosa del genere:

select ProjectName, TotalBudget, EffortToDate from Projects where TotalBudget > X

Non importa se si ottengono i dati direttamente dalle tabelle in cui è archiviato il modello di dominio o se in qualche modo si estraggono i dati in un secondo database, in un data warehouse o altro:

1. Se il tuo archivio dei rapporti è diverso dal tuo effettivo archivio dati, puoi semplicemente copiare i dati dalle "tabelle dei modelli di dominio"
2. Se si esegue una query diretta sul proprio archivio dati effettivo, i dati sono già presenti e non è necessario calcolare nulla

In entrambi i casi, la logica aziendale per i calcoli si trova esattamente in un punto: il modello di dominio.
Non è necessario altrove, quindi non è necessario duplicarlo.