ドメインが豊富なアプリケーションでレポートおよびダッシュボード用のデータを取得するためのベストプラクティスまたは設計パターン
まず、これは軽視されている質問/領域であるように思われるので、この質問を改善する必要がある場合は、他の人に利益をもたらすことができる素晴らしい質問にしてください！試してみたいアイデアだけでなく、この問題を解決するソリューションを実装した人々からのアドバイスやヘルプを探しています。 私の経験では、アプリケーションには2つの側面があります。主にドメイン駆動型で、ユーザーがドメインモデル（アプリケーションの「エンジン」）とやり取りする「タスク」側と、ユーザーがタスク側で何が起こるかに基づいてデータを取得します。 タスク側では、リッチなドメインモデルを備えたアプリケーションにはドメインモデルのビジネスロジックが必要であり、データベースは主に永続化のために使用する必要があることは明らかです。懸念の分離、すべての本はそれについて書かれています、私たちは何をすべきか、素晴らしいを知っています。 レポート側についてはどうですか？データウェアハウスは受け入れ可能ですか、それともデータベースとビジネスそのものにビジネスロジックを組み込んでいるため、設計が悪いのでしょうか。データベースのデータをデータウェアハウスデータに集約するには、データにビジネスロジックとルールを適用している必要があります。そのロジックとルールはドメインモデルからではなく、データ集約プロセスからのものです。それは間違っていますか？ 私は、ビジネスロジックが広範囲にわたる大規模な財務およびプロジェクト管理アプリケーションに取り組んでいます。このデータのレポートを作成するとき、レポート/ダッシュボードに必要な情報を取得するために多くの集計を行うことが多く、集計には多くのビジネスロジックが含まれています。パフォーマンスのために、高度に集約されたテーブルとストアドプロシージャを使用してこれを行っています。 例として、アクティブなプロジェクトのリストを表示するためにレポート/ダッシュボードが必要だとしましょう（10,000個のプロジェクトを想像してください）。各プロジェクトには、次のような一連のメトリックが必要です。 総予算 これまでの努力 燃焼速度 現在の燃焼速度での予算枯渇日 等 これらのそれぞれには、多くのビジネスロジックが含まれます。そして、私は単に数字の乗算やいくつかの単純なロジックについて話しているのではありません。予算を得るために話しているのは、各従業員の時間（一部のプロジェクトでは、他のプロジェクトでは乗数があります）に1つずつ、500の異なるレートのレートシートを適用し、費用や適切なマークアップなどを適用する必要があることですロジックは広範です。クライアントにとって妥当な時間内にこのデータを取得するには、多くの集約とクエリのチューニングが必要でした。 これは最初にドメインを介して実行する必要がありますか？パフォーマンスはどうですか？単純なSQLクエリを使用しても、クライアントが妥当な時間内に表示するのに十分な速度でこのデータを取得することはほとんどありません。これらすべてのドメインオブジェクトをリハイドレートし、アプリケーションレイヤーでデータを混合および照合して集約する場合、またはアプリケーションでデータを集約しようとする場合、クライアントにこのデータを十分に速く取得しようとすることは想像できません。 これらのケースでは、SQLはデータの処理に優れているように思われますが、使用しないのはなぜですか？ただし、ドメインモデルの外部にビジネスロジックがあります。ドメインモデルおよびレポート集計スキームでビジネスロジックを変更する必要があります。 ドメイン駆動設計と優れた実践に関して、アプリケーションのレポート/ダッシュボード部分をどのように設計するかについて、私は本当に困っています。 MVCはデザインフレーバーデュジュールであり、現在のデザインで使用しているため、MVCタグを追加しましたが、レポートデータがこのタイプのアプリケーションにどのように適合するかわかりません。 本、デザインパターン、グーグルのキーワード、記事など、この分野での助けを探しています。このトピックに関する情報が見つかりません。 編集と別の例 今日出会った別の完璧な例。顧客が顧客営業チームのレポートを望んでいる。彼らは単純なメトリックのように見えるものを望んでいます： 各営業担当者の現在までの年間売上はいくらですか？ しかし、それは複雑です。各販売員は複数の販売機会に参加しました。勝った人もいなかった人もいます。各販売機会には、それぞれの役割と参加ごとに、販売に対するクレジットの割合が割り当てられた複数の販売員がいます。それでは、このためにドメインを通過することを想像してください。すべての営業担当者のデータベースからこのデータを引き出すために必要なオブジェクトの再水和の量： すべての取得SalesPeople- > それぞれが得るために彼らのSalesOpportunities- > 各販売の彼らの割合を取得し、その販売量を算出するために 、すべての彼らの最大の追加SalesOpportunity販売量を。 そして、それは1つのメトリックです。または、迅速かつ効率的に実行し、高速に調整できるSQLクエリを作成できます。 編集2- CQRSパターン CQRSパターンについて読んだことがありますが、興味深いことに、Martin Fowlerもテストされていないと言います。それで、過去にこの問題はどのように解決されましたか。これは、何らかの点で全員が直面していなければなりません。成功の実績を持つ確立されたアプローチまたは使い古されたアプローチとは何ですか？ 編集3-レポートシステム/ツール このコンテキストで考慮すべきもう1つのことは、レポートツールです。Reporting Services / Crystal Reports、Analysis Services、Cognoscentiなどはすべて、SQL /データベースからのデータを想定しています。これらのデータが後であなたのビジネスに届くとは思いません。それでも、彼らと彼らのような人々は、多くの大規模システムのレポートの重要な部分です。これらのシステムのデータソースやレポート自体にもビジネスロジックがある場合、これらのデータは適切に処理されますか？