Meilleures pratiques ou modèles de conception pour la récupération des données pour les rapports et les tableaux de bord dans une application riche en domaine

Question

Tout d'abord, je tiens à dire que cela semble être une question/un domaine négligé, donc si cette question doit être améliorée, aidez-moi à en faire une excellente question qui peut profiter aux autres! Je cherche des conseils et de l'aide de personnes qui ont mis en œuvre des solutions qui résolvent ce problème, pas seulement des idées à essayer.

D'après mon expérience, il y a deux côtés d'une application - le côté "tâche", qui est en grande partie piloté par le domaine et où les utilisateurs interagissent richement avec le modèle de domaine (le "moteur" de l'application) et le côté rapports, où les utilisateurs obtenir des données en fonction de ce qui se passe du côté des tâches.

Du côté des tâches, il est clair qu'une application avec un modèle de domaine riche doit avoir une logique métier dans le modèle de domaine et la base de données doit être utilisée principalement pour la persistance. Séparation des préoccupations, chaque livre est écrit à ce sujet, nous savons quoi faire, génial.

Qu'en est-il du côté des rapports? Les entrepôts de données sont-ils acceptables ou sont-ils de mauvaise conception car ils intègrent la logique métier dans la base de données et les données elles-mêmes? Afin d'agréger les données de la base de données en données d'entrepôt de données, vous devez avoir appliqué la logique et les règles métier aux données, et cette logique et ces règles ne provenaient pas de votre modèle de domaine, elles provenaient de vos processus d'agrégation de données. Est-ce faux?

Je travaille sur de grandes applications financières et de gestion de projet où la logique métier est étendue. Lors de la génération de rapports sur ces données, j'ai souvent BEAUCOUP d'agrégations à faire pour extraire les informations requises pour le rapport/tableau de bord, et les agrégations contiennent beaucoup de logique métier. Pour des raisons de performances, je l'ai fait avec des tables hautement agrégées et des procédures stockées.

À titre d'exemple, supposons qu'un rapport/tableau de bord soit nécessaire pour afficher une liste de projets actifs (imaginez 10 000 projets). Chaque projet aura besoin d'un ensemble de métriques avec lui, par exemple:

budget total
effort à ce jour
taux de brûlure
date d'épuisement du budget au taux de combustion actuel
etc.

Chacun de ces éléments implique beaucoup de logique métier. Et je ne parle pas seulement de multiplier les nombres ou d'une logique simple. Je parle afin d'obtenir le budget, vous devez appliquer une feuille de taux avec 500 taux différents, un pour le temps de chaque employé (sur certains projets, d'autres ont un multiplicateur), en appliquant les dépenses et toute majoration appropriée, etc. la logique est vaste. Il a fallu beaucoup d'agrégation et de réglage des requêtes pour obtenir ces données dans un délai raisonnable pour le client.

Est-ce que cela doit être exécuté d'abord sur le domaine? Et la performance? Même avec des requêtes SQL directes, j'obtiens à peine ces données assez rapidement pour que le client les affiche dans un délai raisonnable. Je ne peux pas imaginer essayer d'obtenir ces données au client assez rapidement si je réhydrate tous ces objets de domaine, et mélange et correspond et agrège leurs données dans la couche application, ou essaye d'agréger les données dans l'application.

Il semble que dans ces cas-là, SQL soit bon pour croquer les données, et pourquoi ne pas les utiliser? Mais vous avez alors une logique métier en dehors de votre modèle de domaine. Toute modification de la logique métier devra être modifiée dans votre modèle de domaine et vos schémas d'agrégation de rapports.

Je ne sais vraiment pas comment concevoir la partie reporting/tableau de bord de toute application en ce qui concerne la conception basée sur le domaine et les bonnes pratiques.

J'ai ajouté la balise MVC parce que MVC est la saveur de conception du jour et je l'utilise dans ma conception actuelle, mais je ne peux pas comprendre comment les données de rapport s'intègrent dans ce type d'application.

Je recherche toute aide dans ce domaine - livres, modèles de conception, mots clés pour google, articles, quoi que ce soit. Je ne trouve aucune information sur ce sujet.

MODIFICATION ET UN AUTRE EXEMPLE

Un autre exemple parfait que j'ai rencontré aujourd'hui. Le client souhaite un rapport pour l'équipe de vente client. Ils veulent ce qui semble être une simple métrique:

Pour chaque vendeur, quelles sont ses ventes annuelles à ce jour?

Mais c'est compliqué. Chaque vendeur a participé à plusieurs opportunités de vente. Certains ont gagné, d'autres non. Dans chaque opportunité de vente, plusieurs vendeurs se voient attribuer chacun un pourcentage de crédit pour la vente en fonction de leur rôle et de leur participation. Imaginez maintenant passer par le domaine pour cela ... la quantité de réhydratation des objets que vous auriez à faire pour extraire ces données de la base de données pour chaque vendeur:

Obtenez tous les SalesPeople->
Pour chacun, obtenez leur SalesOpportunities->
Pour chacun, obtenez leur pourcentage de la vente et calculez leur montant de vente
puis Additionnez tous leurs SalesOpportunity Montant des ventes.

Et c'est UNE métrique. Ou vous pouvez écrire une requête SQL qui peut le faire rapidement et efficacement et l'ajuster pour être rapide.

EDIT 2 - modèle CQRS

J'ai lu sur le CQRS Pattern et, tout en intriguant, même Martin Fowler dit que ce n'est pas testé. Alors, comment ce problème a-t-il été résolu dans le passé? Cela doit avoir été rencontré par tout le monde à un moment ou à un autre. Qu'est-ce qu'une approche établie ou bien usée avec un palmarès de succès?

Édition 3 - Systèmes/outils de reporting

Une autre chose à considérer dans ce contexte est les outils de reporting. Reporting Services/Crystal Reports, Analysis Services et Cognoscenti, etc. attendent tous des données de SQL/base de données. Je doute que vos données transitent par votre entreprise ultérieurement pour ces informations. Et pourtant, eux et d'autres comme eux sont une partie vitale du reporting dans de nombreux grands systèmes. Comment les données sont-elles correctement gérées alors qu'il existe même une logique métier dans la source de données de ces systèmes ainsi que, éventuellement, dans les rapports eux-mêmes?

richard · Accepted Answer

C'est 4 ans plus tard et je viens de retrouver cette question, et j'ai quelle est, pour moi, la réponse.

Selon votre application et ses besoins spécifiques, votre base de données de domaine/transaction et vos rapports peuvent être des "systèmes" ou des "moteurs" distincts, ou ils peuvent être gérés par un seul système. Ils doivent cependant être logiquement séparés, ce qui signifie qu'ils utilisent différents moyens pour récupérer et fournir des données à l'interface utilisateur.

Je préfère qu'ils soient physiquement séparés (en plus d'être logiquement séparés), mais souvent vous les démarrez ensemble (physiquement) puis, à mesure que l'application évolue, vous les séparez.

De toute façon, encore une fois, ils devraient être logiquement différents. Il est correct de dupliquer la logique métier dans le système de rapport. L'important est que le système de rapport obtienne la même réponse que le système de domaine - mais les chances sont il y parviendra par différents moyens. Par exemple, votre système de domaine aura une tonne de règles commerciales très strictes implémentées dans le code procédural (probablement). Le système de rapport pourrait implémenter ces mêmes règles lors de la lecture des données, mais le ferait via un code basé sur SET (par exemple SQL).

Voici à quoi pourrait ressembler une évolution de l'architecture de votre application au fur et à mesure de son évolution:

Niveau 1 - Domaine et systèmes de rapports séparés logiquement, mais toujours dans la même base de code et la même base de données

Niveau 2 - Domaine et systèmes de rapports logiquement séparés, mais bases de données distinctes maintenant, avec synchronisation.

Niveau 3 - Domaine et systèmes de rapports séparés logiquement et physiquement, et bases de données séparées avec synchronisation.

L'idée principale est que le reporting et le domaine ont des besoins radicalement différents. Différents profils de données (fréquence de lecture et d'écriture et de mise à jour), exigences de performances différentes, etc. Ils doivent donc être implémentés différemment, ce qui nécessite une certaine duplication de la logique métier.

C'est à votre entreprise de trouver un moyen de maintenir à jour la logique métier du domaine et des systèmes de reporting.

RibaldEddie · Answer

C'est une réponse très simple, mais qui va droit au cœur du problème:

En termes de DDD, pensez peut-être au reporting comme un contexte délimité?, Donc plutôt que de penser en termes de "THE" modèle de domaine, vous devriez être prêt à penser qu'il est acceptable d'avoir plus d'un modèle. Donc, oui, tout va bien si le domaine de rapport contient une logique métier de rapport, tout comme il est normal que le domaine transactionnel contienne une logique métier transactionnelle.

En ce qui concerne, par exemple, les procédures stockées SQL par rapport au modèle de domaine dans le code d'application, les mêmes avantages et inconvénients s'appliquent au système de notification et au système transactionnel.

Comme je vois que vous avez ajouté une prime à la question, j'ai relu la question et j'ai remarqué que vous demandiez des ressources spécifiques à ce sujet, donc j'ai pensé commencer par vous suggérer de regarder d'autres questions de débordement de pile sur le sujet, et j'ai trouvé celui-ci https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

L'essentiel général de celui-ci est d'utiliser CQRS comme modèle pour votre système, qui est cohérent avec DDD, et de s'appuyer sur les responsabilités côté requête pour obtenir des rapports, mais je ne suis pas sûr que ce soit une réponse utile dans ton cas.

J'ai également trouvé ceci http://www.martinfowler.com/bliki/ReportingDatabase.html , que j'ai trouvé lié à partir d'ici: http://groups.yahoo.com/neo/ groups/domaindrivendesign/conversations/topics/2261

Voici un article intéressant d'ACM sur le sujet: http://dl.acm.org/citation.cfm?id=2064685 mais il est derrière un paywall donc je ne peux pas le lire (pas un Membre ACM :().

Il y a aussi cette réponse ici sur une question similaire: https://stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database

et celui-ci: http://snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

J'espère que cela t'aides!

theinsaneone · Answer

Ma compréhension de votre question est la suivante: l'application pour la tâche quotidienne a

Affichage >> Contrôleur >> Modèle (BL) >> Base de données (données)

Demande de déclaration

Affichage >> Contrôleur >> Modèle >> Base de données (données + BL)

Ainsi, le changement de BL pour ' application de tâche ' entraînera un changement dans ' les rapports 'BL aussi. C'est votre vrai problème, non? C'est bien de faire des changements deux fois, cette douleur que vous devez prendre de toute façon. La raison en est que les BL sont séparés par leurs préoccupations respectives. L'un sert à récupérer des données et l'autre à agréger des données. De plus, votre BL d'origine et votre BL agrégé seront écrits dans une technologie ou un langage différent ( C #/Java et SQL proc ). Il n'y a pas d'échappatoire.

Prenons un autre exemple qui n'est pas spécifiquement lié au signalement. Supposons qu'une société XXX effectue le suivi des e-mails de tous les utilisateurs à des fins d'interprétation et vende ces informations à des sociétés de marketing. Maintenant, il aura un BL pour l'interprétation et un BL pour l'agrégation des données pour les sociétés de marketing. Les préoccupations sont différentes pour les deux BL. Demain, si leur BL change de telle sorte que les courriers provenant de Cuba doivent être ignorés, alors la logique commerciale sera modifiée des deux côtés.

Adrian Schneider · Answer

Le reporting est un contexte délimité, ou un sous-domaine, pour parler librement. Il résout un besoin commercial de collecter/agréger des données et de les traiter pour obtenir des informations commerciales.

La façon dont vous implémentez ce sous-domaine sera probablement un équilibre entre la manière (la plus) correcte sur le plan architectural de le faire et ce que votre infrastructure permettra. J'aime partir du premier côté et ne m'orienter vers le second que si nécessaire.

Vous pouvez probablement diviser cela en deux problèmes principaux que vous résolvez:

Agrégation ou stockage des données. Cela devrait traiter une source de données et combiner les informations de manière à ce qu'elles soient stockées dans une autre source de données.
Interroger la source de données agrégée pour fournir des informations commerciales.

Aucun de ces problèmes ne fait référence à une base de données ou à un moteur de stockage spécifique. Votre couche de domaine doit simplement traiter des interfaces, implémentées dans votre couche d'infrastructure par divers adaptateurs de stockage.

Vous pouvez avoir plusieurs travailleurs ou exécuter des travaux planifiés, qui sont divisés en quelques parties mobiles:

Quelque chose à interroger
Quelque chose à agréger
Quelque chose à ranger

J'espère que vous pourrez voir une partie du CQRS briller à travers là.

Du côté des rapports, il ne devrait avoir besoin que d'effectuer des requêtes, mais jamais directement dans la base de données. Parcourez vos interfaces et votre couche de domaine ici. Ce n'est pas le même domaine problématique que vos tâches principales, mais il devrait toujours y avoir une logique à laquelle vous souhaitez adhérer.

Dès que vous plongez directement dans la base de données, vous en dépendez davantage et cela peut éventuellement interférer avec les besoins de données de votre application d'origine.

De plus, au moins pour moi, je préfère certainement écrire des tests et développer du code plutôt que des requêtes ou des procédures stockées. J'aime aussi ne pas m'enfermer dans des outils spécifiques jusqu'à ce que cela soit absolument nécessaire.

duffymo · Answer

Il est typique de séparer les magasins de données opérationnelles/transactionnelles des rapports. Ce dernier peut avoir des exigences pour conserver des données pour des raisons juridiques (par exemple sept ans de données financières pour l'audit financier), et vous ne voulez pas tout cela dans votre magasin de données transactionnelles.

Vous allez donc partitionner vos données transactionnelles par une mesure de temps (hebdomadaire, mensuelle, trimestrielle, annuelle) et déplacer les anciennes partitions dans votre magasin de données de rapport/historique via ETL. Il peut ou non s'agir d'un entrepôt de données avec un schéma en étoile et des dimensions. Vous utiliseriez des outils de création de rapports d'entreposage de données pour effectuer des requêtes et des cumuls ad hoc et des travaux par lots pour générer des rapports périodiques.

Je ne recommanderais pas la création de rapports sur votre magasin de données transactionnelles.

Si vous préférez continuer, voici d'autres réflexions:

"Best" est subjectif et ce qui fonctionne.
J'achèterais un produit de rapport plutôt que de les écrire moi-même.
Si vous utilisez une base de données relationnelle, alors SQL est le seul jeu en ville.
Les procédures stockées dépendent de votre capacité à les écrire.

Un logiciel de gestion de projet que vous utilisez en interne? J'achèterais avant de construire. Quelque chose comme Rally et Microsoft Project.

Michael Brown · Answer

Tout d'abord une terminologie, ce que vous appelez le côté tâche est connu sous le nom de transactionnel et le côté de rapport est Analytics.

Vous avez déjà mentionné le CQRS, qui est une excellente approche, mais son application pratique est peu documentée.

Ce qui a été fortement testé, c'est compléter votre traitement transactionnel avec un moteur de traitement analytique. Ceci est parfois appelé Data Warehousing ou Data Cubes. Le plus gros problème en matière d'analyse est que tenter d'exécuter des requêtes sur vos données transactionnelles en temps réel est au mieux inefficace car il n'est vraiment possible d'optimiser une base de données pour la lecture ou l'écriture. Pour les transactions, vous voulez des vitesses d'écriture élevées pour éviter les retards dans le traitement/l'exécution des tâches. Pour les rapports, vous voulez des vitesses de lecture élevées pour que les décisions puissent être prises.

Comment prendre en compte ces problèmes? L'approche la plus simple à comprendre consiste à utiliser un schéma aplati pour vos rapports et ETL (extraire la charge de transformation) pour transférer les données du schéma transactionnel normalisé vers le schéma analytique dénormalisé. L'ETL est exécuté régulièrement via un agent et précharge le tableau d'analyse afin qu'il soit prêt pour une lecture rapide à partir de votre moteur de génération de rapports.

Un excellent livre pour se familiariser avec l'entreposage de données est le Data Warehouse Toolkit de Ralph Kimball. Pour une approche plus pratique. Téléchargez la version d'essai de SQL Server et prenez le Microsoft Data Warehouse toolkit qui reprend la discussion générale du premier livre mais montre comment appliquer les concepts à l'aide de SQL Server.

Il y a plusieurs livres liés à partir de ces pages qui entrent dans plus de détails sur ETL, Star Schema Design, BI, Dashboards et d'autres sujets pour vous aider à avancer.

Le moyen le plus rapide pour vous rendre de l'endroit où vous vous trouvez à l'endroit où vous voulez être est d'embaucher un expert BI et de le suivre pendant qu'il met en œuvre ce dont vous avez besoin.

Scott Millett · Answer

Qu'en est-il du côté des rapports? Les entrepôts de données sont-ils acceptables ou sont-ils de mauvaise conception car ils intègrent la logique métier dans la base de données et les données elles-mêmes?

Je ne pense pas que vous parliez de logique métier, c'est plus de logique de reporting. Que font les utilisateurs avec les informations sur cet écran, est-ce simplement pour les mises à jour de statut? Votre modèle de domaine est utilisé pour modéliser les opérations transactionnelles, la création de rapports est une préoccupation différente. Extraire les données de SQL Server ou les placer dans un entrepôt de données convient parfaitement aux scénarios de génération de rapports.

Votre modèle de domaine doit appliquer les invariants de votre domaine, par exemple un membre de projet ne peut pas réserver au même projet en même temps, ou ne peut réserver que x nombre d'heures par semaine. Ou vous ne pouvez pas réserver pour ce projet car il est terminé, etc., etc. l'état de votre modèle de domaine (les données) peut être copié pour les rapports séparément.

Pour améliorer les performances des requêtes, vous pouvez utiliser une vue matérialisée. Lorsqu'une opération est validée par rapport à votre modèle (par exemple, Réservez 4 heures de temps à cette personne pour projeter x) et qu'elle réussit, elle peut déclencher un événement que vous pouvez ensuite stocker dans une base de données de rapports et effectuer les calculs nécessaires pour votre rapport. Il sera alors très rapide de l'interroger.

Gardez vos contextes de transaction et de reporting séparés, une base de données relationnelle a été créée pour signaler qu'un modèle de domaine ne l'était pas.

[~ # ~] modifier [~ # ~]

Article de blog utile sur le sujet http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html

MyXEDNotes · Answer

La récupération de grandes quantités d'informations sur des réseaux étendus, y compris Internet, est problématique en raison de problèmes liés à la latence de la réponse, au manque d'accès direct à la mémoire des ressources de service de données et à la tolérance aux pannes.

Cette question décrit un modèle de conception pour résoudre les problèmes de gestion des résultats des requêtes qui renvoient de grandes quantités de données. En règle générale, ces requêtes sont effectuées par un processus client sur un réseau étendu (ou Internet), avec un ou plusieurs niveaux intermédiaires, vers une base de données relationnelle résidant sur un serveur distant.

La solution implique la mise en œuvre d'une combinaison de stratégies de récupération de données, notamment l'utilisation d'itérateurs pour parcourir les ensembles de données et fournir un niveau d'abstraction approprié au client, la double mise en mémoire tampon des sous-ensembles de données, la récupération de données multithread et le découpage des requêtes.

marcocs · Answer

un rapport/tableau de bord est nécessaire pour afficher une liste des projets actifs

L'état de chaque projet doit être stocké sous forme statique, par calcul et les informations bien formatées dans la base de données et toutes les simulations doivent être traitées sur le client en tant que WebApp.

date d'épuisement du budget au taux de combustion actuel

ce type de projection ne doit pas être exécuté à la demande. La gestion de ces informations sur demande, comme effectuer des calculs sur les ressources, le taux, les tâches, les jalons, etc., entraînera une utilisation intensive des couche de calcul sans réutilisation de ces résultats pour les appels futurs.

En imaginant un environnement distribué ( cloud privé ou public ), vous obtiendrez les coûts énormes dans la couche de calcul, la faible utilisation de la base de données et le manque total de cache.

Est-ce que cela doit être exécuté d'abord sur le domaine? Et la performance?

La conception de votre logiciel doit inclure la possibilité d'effectuer la normalisation des calculs nécessaires pour obtenir le résultat requis lors de la "saisie de données", pas lors de la lecture. Cette approche réduit considérablement l'utilisation des ressources informatiques, et surtout crée des tables qui peuvent être considérées comme "en lecture seule" par le client. Il s'agit de la première étape pour créer un mécanisme de mise en cache solide et simple.

Donc, une recherche d'abord, avant de terminer l'architecture logicielle, cela pourrait être Distributed Cache System.

(demande: agrégation)! = 1: 1

Ma considération est donc (pour le premier et le deuxième exemple), d'essayer de comprendre quand il convient de normaliser les données, ayant pour objectif de réduire les agrégations par demande client. Ce qui ne peut pas être 1: 1 (demande: agrégation) si un objectif est d'obtenir un système durable.

Distribuer le calcul sur le client

Une autre question, avant de terminer la conception du logiciel, ce pourrait être, combien de normalisation, nous souhaitons déléguer au navigateur du client?

Il a été nommé [~ # ~] mv [~ # ~] *, il est vrai qu'il est à la mode aujourd'hui, en plus de cela, l'un des son but est de créer WebApp (application à page unique), qui peut être considérée comme le présent de nombreuses applications complexes (et heureusement pour les factures que nous payons au fournisseur de cloud, celles-ci sont exécutées dans le client).

Ma conclusion est donc de:

Comprendre combien d'opérations sont vraiment nécessaires pour effectuer la présentation des données;
Analysez combien de ces opérations peuvent être effectuées en arrière-plan (puis distribuées via un système de cache, après leur normalisation);
Comprendre combien d'opérations peuvent être exécutées dans le client, obtenir la configuration des projets, l'exécuter sur des vues sur la WebApp et ainsi réduire le calcul effectué en back-end;

Yugang Zhou · Answer

Utiliser le cache pour la requête, utiliser le domaine pour la mise en cache.

Il existe une fonctionnalité appelée "top utilisateurs" sur stackoverflow. Vous pouvez trouver une ligne sur le bout de la page des meilleurs utilisateurs, dit "Seules les questions et réponses non-wiki communautaire sont incluses dans ces totaux ( mis à jour quotidiennement ) ". Cela indique que les données sont mises en cache.

Mais pourquoi?

Pour des problèmes de performances peut-être. Peut-être qu'ils ont le même problème avec la fuite de la logique du domaine ("Seules les questions et réponses non-wiki communautaire sont incluses dans ces totaux" dans ce cas).

Comment?

Je ne sais pas vraiment comment ils ont fait ça, alors voici juste une supposition :)

Tout d'abord, nous devons trouver des questions/réponses cibles. Une tâche de planification pourrait fonctionner, il suffit de récupérer toutes les cibles potentielles.

Deuxièmement, regardons une seule question/réponse. S'agit-il d'un wiki non communautaire? Est-ce dans les 30 jours? Il est assez facile de répondre avec des modèles de domaine. Comptez les votes et mettez-les en cache si vous êtes satisfait.

Maintenant, nous avons le cache, ils sont la sortie des dérivations de domaine. La requête est rapide et facile car il n'y a que des critères simples à appliquer.

Et si les résultats devaient être plus "en temps réel"?

Les événements peuvent aider. Au lieu de déclencher la mise en cache avec une tâche de planification, nous pouvons diviser le processus en plusieurs sous-processus. Par exemple, lorsque quelqu'un vote sur la réponse de l'hippoom, nous publions un événement déclenchant la mise à jour du cache des meilleurs utilisateurs de l'hippoom. Dans ce cas, nous pouvons voir de petites tâches rapides et fréquentes.

Le CQRS est-il nécessaire?

Ni avec l'approche des tâches de planification ni avec l'approche des événements. Mais cqrs a un avantage. Le cache est généralement très orienté affichage, si certains éléments ne sont pas nécessaires au début, nous ne pouvons pas du tout les calculer et les mettre en cache. CQRS avec sourcing d'événements permet de reconstituer le cache des données historiques en relisant les événements.

Quelques questions connexes:
1 . https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2 . https: // stackoverflow .com/questions/19414951/comment utiliser un domaine riche avec des opérations massives/19416703 # 194167

J'espère que cela aide :)

Christian Specht · Answer

Avertissement:
Je suis assez inexpérimenté dans les applications avec des modèles de domaine.
Je comprends tous les concepts, et je réfléchis depuis longtemps à la façon d'appliquer ces concepts aux applications sur lesquelles je travaille (qui SONT domaine- riche, mais sans OO, modèles de domaine réels, etc.) .
Cette question est également l'un des principaux problèmes auxquels j'ai été confronté. J'ai une idée de comment résoudre ce problème, mais comme je viens de le dire ... c'est juste une idée que j'ai eue.
Je ne l'ai pas encore implémenté dans un projet réel, mais je ne vois pas pourquoi cela ne devrait pas fonctionner.

Maintenant que je l'ai dit clairement, voici ce que j'ai trouvé - je vais utiliser votre premier exemple (les mesures du projet) pour expliquer:

Quand quelqu'un modifie un projet, vous le chargez et l'enregistrez de toute façon via votre modèle de domaine.
En ce moment, vous avez toutes les informations chargées pour calculer toutes vos mesures (budget total, effort à ce jour, etc.) pour ce projet.

Vous pouvez le calculer dans le modèle de domaine et l'enregistrer dans la base de données avec le reste du modèle de domaine.
Ainsi, la classe Project dans votre modèle de domaine aura certaines propriétés comme TotalBudget, EffortToDate etc., et il y aura également des colonnes avec ces noms dans le tables de base de données où votre modèle de domaine est stocké (dans les mêmes tables, ou dans une table séparée ... n'a pas d'importance) .

Bien sûr, vous devez effectuer une exécution unique pour calculer la valeur de tous les projets existants au début. Mais après cela, les données sont automatiquement mises à jour avec les valeurs calculées actuelles chaque fois qu'un projet est modifié via le modèle de domaine.

Donc, chaque fois que vous avez besoin d'un rapport, toutes les données requises sont déjà là (pré-calculé) et vous pouvez simplement faire quelque chose comme ceci:

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

Peu importe que vous obteniez les données directement à partir des tables où le modèle de domaine est stocké, ou si vous extrayez les données vers une deuxième base de données, vers un entrepôt de données ou autre:

Si votre magasin de rapports est différent de votre magasin de données réel, vous pouvez simplement copier les données des "tables de modèle de domaine"
Si vous interrogez directement votre magasin de données réel, les données sont déjà là et vous n'avez pas besoin de calculer quoi que ce soit

Dans les deux cas, la logique métier pour les calculs est exactement à un endroit: le modèle de domaine.
Vous n'en avez pas besoin ailleurs, il n'est donc pas nécessaire de le dupliquer.