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

Premièrement, je tiens à dire que cela semble être une question ou un domaine négligé. Si cette question doit être améliorée, aidez-moi à faire de cette question une excellente question qui pourra profiter à d’autres! Je cherche des conseils et de l'aide auprès de personnes qui ont mis en place des solutions pour résoudre ce problème, pas seulement des idées à essayer.

D'après mon expérience, il existe deux côtés d'une application - le côté "tâche", qui est largement dirigé par un domaine et où les utilisateurs interagissent de manière riche avec le modèle de domaine (le "moteur" de l'application) et le côté rapport, où les utilisateurs obtenir des données en fonction de ce qui se passe du côté de la tâche.

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 que la base de données doit être principalement utilisée 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? Pour agréger les données de la base de données en données d'entrepôt de données, vous devez avoir appliqué une logique et des règles commerciales aux données, et cette logique et ces règles ne proviennent pas de votre modèle de domaine, mais 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 très développée. Lors de la génération de rapports sur ces données, j'aurai souvent beaucoup d'agrégations à effectuer 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 le faisais avec des tables hautement agrégées et des procédures stockées.

Par exemple, supposons qu'un rapport / tableau de bord soit nécessaire pour afficher une liste des projets actifs (imaginez 10 000 projets). Chaque projet nécessitera un ensemble de métriques, par exemple:

1. budget total
2. effort à ce jour
3. taux de combustion
4. date d'épuisement du budget au taux de combustion actuel
5. etc.

Chacune de celles-ci implique beaucoup de logique métier. Et je ne parle pas seulement de la multiplication de nombres ou d'une simple logique. Je parle pour 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), l'application des dépenses et toute majoration appropriée, etc. la logique est vaste. Il a fallu beaucoup d’agrégation et d’ajustement des requêtes pour obtenir ces données dans un délai raisonnable pour le client.

Est-ce que cela devrait être exécuté en premier dans le domaine? Qu'en est-il de la performance? Même avec des requêtes SQL directes, ces données me parviennent à peine assez rapidement pour que le client puisse les afficher dans un délai raisonnable. Je ne peux pas imaginer essayer de transmettre ces données au client assez rapidement si je réhydrate tous ces objets de domaine, puis je mélange, compare et agrège leurs données dans la couche d'application ou essaie d'agréger les données dans l'application.

Dans ces cas, il semble que SQL soit efficace pour traiter des données, et pourquoi ne pas l'utiliser. Mais alors vous avez une logique métier en dehors de votre modèle de domaine. Toute modification de la logique applicative 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 rapport / tableau de bord de toute application en ce qui concerne la conception axée sur les domaines et les bonnes pratiques.

J'ai ajouté la balise MVC car MVC est la variante 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 cherche de l'aide dans ce domaine - livres, modèles de conception, mots clés de Google, articles, etc. Je ne trouve aucune information sur ce sujet.

EDIT ET UN AUTRE EXEMPLE

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

Quelles sont leurs ventes annuelles pour chaque vendeur?

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 par rôle et participation. Imaginez maintenant que vous parcouriez le domaine pour cela ... la quantité de réhydratation d'objets que vous auriez à faire pour extraire ces données de la base de données pour chaque vendeur:

Obtenez tous les SalesPeople->
Pour chaque obtenir leur SalesOpportunities->
Pour chaque obtenir leur pourcentage de la vente et calculer leur montant des ventes
puis additionnez tout leur SalesOpportunitymontant 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’accorder pour qu’elle soit rapide.

EDIT 2 - Pattern CQRS

J'ai lu sur le modèle CQRS et, bien que très intriguant, même Martin Fowler a déclaré qu'il n'était pas testé. Alors, comment ce problème a-t-il été résolu dans le passé? Tout le monde a dû faire face à cela à un moment ou à un autre. Qu'est-ce qu'une approche établie ou bien utilisée avec un historique de succès?

Edition 3 - Systèmes de reporting / Outils

Une autre chose à considérer dans ce contexte concerne les outils de reporting. Reporting Services / Crystal Reports, Analysis Services et Cognoscenti, etc. attendent tous des données SQL / base de données. Je doute que vos données soient transmises ultérieurement à votre entreprise. Et pourtant, eux et d’autres comme eux jouent un rôle essentiel dans la génération de rapports dans de nombreux systèmes de grande taille. Comment les données de ces systèmes sont-elles correctement gérées s'il existe même une logique métier dans la source de données de ces systèmes et éventuellement dans les rapports eux-mêmes?

C'est une réponse très simple, mais je vais au coeur du problème:

En termes de DDD, pensez peut-être que la création de rapports est un contexte limité? Ainsi, plutôt que de penser en termes de "modèle" de domaine, vous devriez être prêt à penser qu'il est normal d'avoir plusieurs modèles. Alors oui, le domaine de génération de rapports contient une logique métier de création de rapports, tout comme il est acceptable que le domaine transactionnel contienne une logique de gestion transactionnelle.

En ce qui concerne la question des procédures stockées SQL par rapport au modèle de domaine dans le code de l’application, les mêmes avantages et inconvénients s’appliquent au système de génération de rapports que pour le système transactionnel.

Puisque je vois que vous avez ajouté une prime à la question, j'ai relu la question et remarqué que vous demandez une ressource spécifique à ce sujet. J'ai donc pensé commencer par vous suggérer de regarder d'autres questions Stack Overflow sur le sujet, et j'ai trouvé celui-ci https://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

L’essentiel de cette idée est d’utiliser CQRS comme modèle pour votre système, ce qui est conforme à DDD, et de s’appuyer sur les responsabilités de la requête pour obtenir des rapports, mais je ne suis pas sûr que ce soit une réponse utile. ton cas.

J'ai aussi trouvé ce http://www.martinfowler.com/bliki/ReportingDatabase.html , que j'ai trouvé lié à partir de: 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 se trouve derrière un paywall et je ne peux donc pas le lire (pas un membre d'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!

D'après ce que j'ai compris de votre question, voici: l'application pour les tâches quotidiennes a

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

Demande de rapport

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

Donc, changer dans BL pour ' application de tâche ' entraînera aussi un changement dans ' rapporter ' BL. C'est ton vrai problème non? Eh bien, ça va de faire des changements deux fois, cette douleur que vous devez prendre de toute façon. La raison en est que les deux BL sont séparés par leurs préoccupations respectives. L'un est destiné à l'extraction de données et l'autre à l'agrégation de données. En outre, votre BL d'origine et votre BL agrégateur 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, non lié à la déclaration spécifique Supposons qu'une entreprise XXX traque les mails de tous les utilisateurs pour interprétation et vende ces informations à des sociétés de marketing. Désormais, il disposera d'un BL pour l'interprétation et d'un BL pour l'agrégation de données destinées aux 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 en provenance de Cuba doivent être ignorés, la logique commerciale sera modifiée des deux côtés.

La déclaration est un contexte délimité, ou un sous-domaine, pour parler librement. Il résout le besoin des entreprises de collecter / agréger des données et de les traiter pour obtenir des informations décisionnelles.

La manière dont vous implémenterez ce sous-domaine constituera probablement un équilibre entre la manière (la plus) architecturale correcte de le faire et ce que votre infrastructure autorisera. J'aime commencer du premier côté et ne me diriger vers ce dernier que si cela est nécessaire.

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

1. Agrégation ou entreposage de données. Cela devrait traiter certaines sources de données et combiner les informations de manière à ce qu'elles soient stockées dans une autre source de données.

2. Interroger la source de données agrégée pour fournir des informations décisionnelles.

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

Vous pouvez avoir plusieurs travailleurs ou une tâche planifiée exécutée, qui est divisée en quelques pièces mobiles:

• Quelque chose à interroger
• Quelque chose à agréger
• Quelque chose à stocker

J'espère que vous pourrez voir une partie du CQRS briller par 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. Passez par vos interfaces et par votre couche de domaine ici. Ce n'est pas le même problème que vos tâches principales, mais vous devez quand même avoir une certaine logique à respecter.

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

En outre, du moins pour moi, je préfère définitivement écrire des tests et développer en 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 avant que cela soit absolument nécessaire.

Il est typique de séparer les magasins de données opérationnels / transactionnels des rapports. Ce dernier peut être obligé de conserver des données pour des raisons juridiques (par exemple, sept ans de données financières pour un 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 temporelle (hebdomadaire, mensuelle, trimestrielle, annuelle) et déplacer des partitions plus anciennes dans votre magasin de données de génération de rapports / historique via ETL. Il peut s'agir ou non d'un entrepôt de données avec un schéma en étoile et des dimensions. Vous utiliseriez des outils de génération de rapports d'entreposage de données pour effectuer des requêtes ad hoc, des cumuls 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 transactionnel.

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

1. "Le meilleur" est subjectif et ce qui fonctionne.
2. Je voudrais acheter un produit de rapport plutôt que de les écrire moi-même.
3. Si vous utilisez une base de données relationnelle, SQL est le seul jeu en ville.
4. Les procédures stockées dépendent de votre capacité à les écrire.

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

Tout d’abord une terminologie, ce que vous appelez le côté tâche est appelé transactionnel et le côté reporting 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é largement testé, c'est de compléter votre traitement transactionnel avec un moteur de traitement analytique. Ceci est parfois appelé Data Warehousing ou Data Cubes. Le plus grand inconvénient 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 est vraiment possible d'optimiser une base de données en lecture ou en écriture. Pour les transactions, vous voulez des vitesses d’écriture élevées pour éviter les retards de traitement / d’exécution. Pour les rapports, vous voulez des vitesses de lecture élevées afin que des décisions puissent être prises.

Comment rendre compte de ces problèmes? L’approche la plus simple à comprendre consiste à utiliser un schéma aplati pour vos rapports et à l’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 par 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.

Le Data Warehouse Toolkit de Ralph Kimball est un excellent livre pour se familiariser avec l’entreposage de données . Pour une approche plus pratique. Téléchargez la version d'essai de SQL Server et récupérez la boîte à outils Microsoft Data Warehouse qui reprend la discussion générale du premier livre mais montre comment appliquer les concepts à l'aide de SQL Server.

Plusieurs livres liés à partir de ces pages donnent plus de détails sur ETL, Star Schema Design, la BI, les tableaux de bord, etc., pour vous aider à progresser.

Le moyen le plus rapide de vous rendre où vous voulez est de faire appel à un expert en BI et de l’observer pendant qu’il met en œuvre ce dont vous avez besoin.

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 au temps de réponse, au manque d'accès direct à la mémoire aux ressources de traitement des données et à la tolérance aux pannes.

Cette question décrit un modèle de conception permettant de résoudre les problèmes de traitement des résultats issus de requêtes renvoyant de grandes quantités de données. Généralement, 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, y compris 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 de requête.

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 d’une logique de reporting. Que font les utilisateurs avec les informations affichées sur cet écran? S'agit-il simplement de mises à jour de statut? Votre modèle de domaine est utilisé pour modéliser les opérations transactionnelles. La création de rapports pose un problème différent. Extraire les données de SQL Server ou les placer dans un entrepôt de données convient parfaitement aux scénarios de rapport.

Votre modèle de domaine doit appliquer les invariants de votre domaine, par exemple un membre du projet ne peut pas effectuer la réservation au même projet au même moment, 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 complet, etc., etc. L’état de votre modèle de domaine (les données) peut être copié pour la création de 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 effectuée sur votre modèle (par exemple, réservez 4 heures de temps au projet x) et qu'elle réussit, elle peut générer un événement que vous pouvez ensuite stocker dans une base de données de rapports et effectuer les calculs nécessaires à votre rapport. Il sera alors très rapide d'interroger à ce sujet.

Gardez vos transactions et contextes de reporting séparés, une base de données relationnelle a été construite pour signaler un modèle de domaine.

MODIFIER

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

Quatre ans plus tard, je viens juste de retrouver cette question et j'ai ce qui est, pour moi, la réponse.

En fonction de votre application et de ses besoins spécifiques, votre base de données de domaines / transactions et vos rapports peuvent être des "systèmes" ou des "moteurs" distincts, ou bien 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 extraire 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) et ensuite, à mesure que l'application mûrit, 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 reporting. L'important est que le système de génération de rapports obtienne la même réponse que le système de domaine - mais il y a des chances qu'il y parvienne par des moyens différents. Par exemple, votre système de domaine aura une tonne de règles métier très strictes implémentées dans le code de procédure (probable). Le système de génération de rapports pourrait appliquer ces mêmes règles lors de la lecture des données, mais le faire via un code basé sur SET (par exemple, SQL).

Voici à quoi une évolution de l'architecture de votre application peut ressembler de manière réaliste à mesure qu'elle évolue:

Niveau 1 - Systèmes de domaine et de génération 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 - Systèmes de reporting et de domaine séparés de manière logique, mais bases de données séparées à présent, avec synchronisation.

Niveau 3 - Systèmes de génération de rapports et de domaines séparés logiquement et physiquement, et bases de données distinctes 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 mises à 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.

Il appartient à votre entreprise de trouver un moyen de maintenir la logique métier du domaine et les systèmes de reporting en parfaite adéquation.

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 d'informations statiques, calculées et bien formatées dans la base de données, et toutes les simulations doivent être géré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 à la demande, telles que les calculs de ressources, de taux, de tâches, de jalons, etc., entraînera une utilisation intensive de la couche de calcul sans aucune réutilisation de ces résultats pour les futurs appels.

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

Est-ce que cela devrait être exécuté en premier dans le domaine? Qu'en est-il de 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", et non lors de la lecture. Cette approche réduit considérablement l'utilisation des ressources informatiques et crée avant tout des tables pouvant être considérées comme "en lecture seule" par le client. C'est la première étape pour créer un mécanisme de mise en cache simple et solide.

Donc, une première recherche, avant de terminer l’architecture logicielle, pourrait être un système de cache distribué .

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

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

Distribuer le calcul sur le client

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

Il a été nommé MV *, il est vrai qu’il est à la mode aujourd’hui. En plus de cela, l’un de ses objectifs est de créer WebApp (une seule page), qui peut être considéré comme le présent de nombreuses applications complexes (et heureusement pour nous payons au fournisseur de cloud, ceux-ci sont exécutés dans le client).

Ma conclusion est donc de:

1. Comprendre combien d'opérations sont vraiment nécessaires pour effectuer la présentation des données;

2. Analysez le nombre de tâches pouvant être effectuées en arrière-plan (puis distribuées via un système de cache après leur normalisation);

3. Comprendre le nombre d'opérations pouvant être exécutées dans le client, obtenir la configuration des projets, l'exécuter sur Vues sur la WebApp et réduire ainsi le calcul effectué en back-end;

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

Il existe une fonctionnalité appelée "principaux utilisateurs" sur stackoverflow. Vous pouvez trouver une ligne sur le bas de la page des principaux utilisateurs, indiquant "Seules les questions et réponses autres que celles du wiki de la communauté sont incluses dans ces totaux ( mises à jour quotidiennement )". Cela indique que les données sont mises en cache.

Mais pourquoi?

Pour problème de performance peut-être. Peut-être ont-ils le même souci avec la logique de domaine qui fuit ("Seules les questions et réponses non-communautaires-wiki sont incluses dans ces totaux" dans ce cas).

Comment?

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

Premièrement, nous devons trouver une question / réponse ciblée. Une tâche de planification peut fonctionner. Il suffit d'extraire toutes les cibles potentielles.

Deuxièmement, examinons une seule question / réponse. Est-ce 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’ya que des critères simples à appliquer.

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

Les événements peuvent faire l'aide. 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 hippoom, nous publions un événement déclenchant la mise à jour du cache des principaux utilisateurs de l'hippoom. Dans ce cas, nous pouvons voir fréquemment de petites tâches rapides.

Le CQRS est-il nécessaire?

Ni avec l'approche de la tâche 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 requis au début, nous ne pouvons pas les calculer ni les mettre en cache du tout. CQRS avec sourcing d'événements permet de reconvertir le cache pour les données historiques en relisant les événements.

Quelques questions connexes:
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use -rich-domain-with-massive-operations / 19416703 # 19416703

J'espère que ça aide :)

Clause de non-responsabilité:
Je suis assez peu expérimenté dans les applications avec des modèles de domaine.
Je comprends tous les concepts et je réfléchis déjà depuis longtemps à la façon de les appliquer aux applications sur lesquelles je travaille (qui sont riches en domaines, mais qui manquent d’OO, de modèles de domaine réels, etc.) .
Cette question est l’un des principaux problèmes que j’ai rencontrés. J'ai une idée de comment résoudre ceci, mais comme je viens de le dire ... c'est juste une idée que j'ai proposée.
Je ne l'ai pas encore implémenté dans un projet réel, mais je ne vois pas pourquoi cela ne fonctionnerait pas, cependant.

Maintenant que j'ai bien expliqué cela, voici ce que j'ai proposé - je vais utiliser votre premier exemple (les métriques du projet) pour expliquer:

Quand quelqu'un édite un projet, vous le chargez et vous enregistrez quand même via votre modèle de domaine.
À ce moment, vous avez toutes les informations chargées pour calculer toutes vos statistiques (budget total, effort à date, etc.) pour ce projet.

Vous pouvez calculer cela 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 Projectclasse dans votre modèle de domaine aura des propriétés comme TotalBudget, EffortToDateetc., et il y aura aussi des colonnes avec ces noms dans les 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 ... doesn peu importe) .

Bien entendu, vous devez effectuer une analyse ponctuelle pour calculer la valeur de tous les projets existants au moment où vous commencez. Mais après cela, les données sont automatiquement mises à jour avec les valeurs calculées actuelles chaque fois qu'un projet est édité via le modèle de domaine.

Ainsi, chaque fois que vous avez besoin d'un rapport quelconque, toutes les données requises sont déjà présentes (pré-calculées) 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 que vous les extrayiez d'une manière ou d'une autre dans une deuxième base de données, dans un entrepôt de données ou autre:

1. Si votre magasin de rapports est différent de votre magasin de données réel, vous pouvez simplement copier les données à partir des "tables de modèle de domaine".
2. Si vous interrogez directement votre magasin de données réel, les données sont déjà là et vous n'avez rien à calculer.

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