ドメインが豊富なアプリケーションでレポートおよびダッシュボード用のデータを取得するためのベストプラクティスまたは設計パターン

まず、これは軽視されている質問/領域であるように思われるので、この質問を改善する必要がある場合は、他の人に利益をもたらすことができる素晴らしい質問にしてください！試してみたいアイデアだけでなく、この問題を解決するソリューションを実装した人々からのアドバイスやヘルプを探しています。

私の経験では、アプリケーションには2つの側面があります。主にドメイン駆動型で、ユーザーがドメインモデル（アプリケーションの「エンジン」）とやり取りする「タスク」側と、ユーザーがタスク側で何が起こるかに基づいてデータを取得します。

タスク側では、リッチなドメインモデルを備えたアプリケーションにはドメインモデルのビジネスロジックが必要であり、データベースは主に永続化のために使用する必要があることは明らかです。懸念の分離、すべての本はそれについて書かれています、私たちは何をすべきか、素晴らしいを知っています。

レポート側についてはどうですか？データウェアハウスは受け入れ可能ですか、それともデータベースとビジネスそのものにビジネスロジックを組み込んでいるため、設計が悪いのでしょうか。データベースのデータをデータウェアハウスデータに集約するには、データにビジネスロジックとルールを適用している必要があります。そのロジックとルールはドメインモデルからではなく、データ集約プロセスからのものです。それは間違っていますか？

私は、ビジネスロジックが広範囲にわたる大規模な財務およびプロジェクト管理アプリケーションに取り組んでいます。このデータのレポートを作成するとき、レポート/ダッシュボードに必要な情報を取得するために多くの集計を行うことが多く、集計には多くのビジネスロジックが含まれています。パフォーマンスのために、高度に集約されたテーブルとストアドプロシージャを使用してこれを行っています。

例として、アクティブなプロジェクトのリストを表示するためにレポート/ダッシュボードが必要だとしましょう（10,000個のプロジェクトを想像してください）。各プロジェクトには、次のような一連のメトリックが必要です。

1. 総予算
2. これまでの努力
3. 燃焼速度
4. 現在の燃焼速度での予算枯渇日
5. 等

これらのそれぞれには、多くのビジネスロジックが含まれます。そして、私は単に数字の乗算やいくつかの単純なロジックについて話しているのではありません。予算を得るために話しているのは、各従業員の時間（一部のプロジェクトでは、他のプロジェクトでは乗数があります）に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 /データベースからのデータを想定しています。これらのデータが後であなたのビジネスに届くとは思いません。それでも、彼らと彼らのような人々は、多くの大規模システムのレポートの重要な部分です。これらのシステムのデータソースやレポート自体にもビジネスロジックがある場合、これらのデータは適切に処理されますか？

これは非常に素直な答えですが、問題の核心に正しく入ります：

DDDの観点からは、レポートを境界コンテキストとして考えるかもしれません。したがって、「THE」ドメインモデルの観点で考えるのではなく、複数のモデルを用意しても問題ないと考えるべきです。そのため、トランザクションドメインにトランザクションビジネスロジックが含まれていてもよいのと同様に、レポートドメインにレポートビジネスロジックが含まれていてもかまいません。

たとえば、SQLストアドプロシージャとアプリケーションコードのドメインモデルの問題に関しては、トランザクションシステムと同じ長所と短所がレポートシステムに適用されます。

あなたが質問に報奨金を追加したことがわかるので、質問をもう一度読んで、これに関する特定のリソースを求めていることに気づいたので、問題に関する他のStack Overflow質問を見て提案することから始めると思いました、そしてこれを見つけましたhttps://stackoverflow.com/questions/11554231/how-does-domain-driven-design-handle-reporting

その1つの一般的な要点は、CQRSをシステムのパターンとして使用することであり、これはDDDと一貫性があり、レポート作成を行う方法としてクエリ側の責任に依存していますが、それが役立つ答えかどうかはわかりませんあなたの場合。

また、このhttp://www.martinfowler.com/bliki/ReportingDatabase.htmlを見つけました。ここからリンクされています：http : //groups.yahoo.com/neo/groups/domaindrivendesign/conversations/topics/2261

これに関するACMの興味深い記事は次のとおりです。http： //dl.acm.org/citation.cfm？id = 2064685しかし、ペイウォールの背後にあるため、実際には読むことができません（ACMメンバーではありません:(）。

同様の質問に対する回答もここにあります：https : //stackoverflow.com/questions/3380431/cqrs-ddd-synching-reporting-database

そしてこれ：http : //snape.me/2013/05/03/applying-domain-driven-design-to-data-warehouses/

お役に立てれば！

あなたの質問から私の理解はこれです：毎日のタスクのアプリケーションが持っています

表示>>コントローラー>>モデル（BL）>>データベース（データ）

報告目的の申請

表示>>コントローラー>>モデル>>データベース（データ+ BL）

したがって、「タスクアプリケーション」のBL を変更すると、「レポート」BLも変更されます。それはあなたの本当の問題ですよね？2回変更しても問題ありません。とにかく苦労しなければなりません。その理由は、両方のBLがそれぞれの懸念によって分離されているためです。1つはデータのフェッチ用で、もう1つはデータの集約用です。また、元のBLと集約BLは、異なるテクノロジーまたは言語（C＃/ javaおよびSQL proc）で記述されます。逃げ場はありません。

特にレポートに関係しない別の例を見てみましょう。会社XXXがすべてのユーザーのメールを追跡して解釈し、その情報をマーケティング会社に販売するとします。これで、解釈用のBLとマーケティング会社用のデータの集計用のBLが1つ作成されます。懸念は両方のBLで異なります。明日、キューバからのメールを無視するようにBLが変更された場合、ビジネスロジックは両側で変更されます。

レポートは、大まかに言えば、限定されたコンテキストまたはサブドメインです。データを収集/集約し、それを処理してビジネスインテリジェンスを取得するというビジネス上のニーズを解決します。

このサブドメインをどのように実装するかは、これを行うことができる（最も）アーキテクチャ的に正しい方法と、インフラストラクチャで許可されるものとのバランスになります。前者から始めて、必要な場合にのみ後者に向かって移動するのが好きです。

おそらくこれを、解決しようとしている2つの主要な問題に分けることができます。

1. データの集約または保管。これにより、何らかのデータソースが処理され、別のデータソースに格納されるように情報が結合されます。

2. 集約されたデータソースを照会して、ビジネスインテリジェンスを提供します。

これらの問題は、特定のデータベースやストレージエンジンを参照するものではありません。ドメインレイヤーは、さまざまなストレージアダプターによってインフラストラクチャレイヤーに実装されたインターフェイスのみを処理する必要があります。

さまざまなワーカーまたはいくつかのスケジュールされたジョブを実行し、いくつかの可動部分に分割することができます。

• 照会するもの
• 集約するもの
• 保管するもの

うまくいけば、CQRSの一部がそこを通して輝いているのを見ることができます。

レポート側では、クエリを実行するだけで、データベースに直接アクセスする必要はありません。ここでインターフェイスとドメインレイヤーを確認します。これはあなたの主要なタスクと同じ問題領域ではありませんが、ここにはあなたが固守したいロジックがまだあるはずです。

データベースに直接飛び込むとすぐにデータベースに依存するようになり、最終的に元のアプリケーションのデータニーズに干渉する可能性があります。

また、少なくとも私にとっては、クエリやストアドプロシージャよりもテストを記述してコードで開発することを間違いなく好みます。また、絶対に必要になるまで特定のツールに縛られないことが好きです。

通常、運用/トランザクションデータストアをレポートから分離します。後者には、法的な理由でデータを保持する必要がある場合があり（たとえば、財務監査用の7年間の財務データ）、トランザクションデータストアにすべてを保存する必要はありません。

そのため、トランザクションデータを一定の時間単位（毎週、毎月、四半期、毎年）でパーティション分割し、ETLを介して古いパーティションをレポート/履歴データストアに移動します。スタースキーマとディメンションを持つデータウェアハウスである場合とそうでない場合があります。データウェアハウジングレポートツールを使用して、アドホッククエリ、ロールアップ、バッチジョブを実行し、定期的なレポートを生成します。

トランザクションデータストアに対するレポートはお勧めしません。

押し続けることを好む場合、より多くの考えはここにあります：

1. 「ベスト」は主観的であり、何が機能するかです。
2. 自分で作成するのではなく、レポート製品を購入します。
3. リレーショナルデータベースを使用している場合、SQLは町で唯一のゲームです。
4. ストアドプロシージャは、作成するスキルがあるかどうかによって異なります。

社内で使用するプロジェクト管理ソフトウェアですか？ビルドする前に購入します。RallyやMicrosoft Projectのようなもの。

最初にいくつかの用語を使用します。タスク側と呼ばれるものはトランザクションと呼ばれ、レポート側は分析です。

素晴らしいアプローチであるCQRSについては既に説明しましたが、このアプローチの実用的なアプリケーションはほとんど文書化されていません。

徹底的にテストされているのは、トランザクション処理を分析処理エンジンで補完することです。これは、データウェアハウジングまたはデータキューブと呼ばれることもあります。分析に関する最大の落とし穴は、トランザクションデータに対してリアルタイムでクエリを実行しようとしても、読み取りまたは書き込み用にデータベースを最適化することしかできないため、非効率であることです。トランザクションの場合、処理/実行の遅延を回避するために、書き込み速度を高速にする必要があります。レポートを作成するには、高い読み取り速度が必要であるため、意思決定を行うことができます。

これらの問題を説明する方法は？理解する最も簡単なアプローチは、レポートとETL（変換負荷の抽出）にフラット化されたスキーマを使用して、正規化されたトランザクションスキーマから非正規化された分析スキーマにデータをシャトルすることです。ETLはエージェントを介して定期的に実行され、分析テーブルをプリロードするため、レポートエンジンからすばやく読み取ることができます。

データウェアハウジングについて理解を深めるのに最適な本は、Ralph KimballによるData Warehouse Toolkitです。より実践的なアプローチのために。SQL Serverの試用版をダウンロードし、Microsoft Data Warehouseツールキットを入手してください。このツールキットでは、最初の本の一般的な説明を取り上げますが、SQL Serverを使用して概念を適用する方法を示します。

これらのページには、ETL、スタースキーマデザイン、BI、ダッシュボード、およびその他のトピックに関する詳細にリンクされた書籍がいくつかあります。

現在地から目的地に到達するための最も簡単な方法は、BIエキスパートを雇い、必要なものを実装する間に彼をシャドウイングすることです。

インターネットを含む広域ネットワークで大量の情報を取得することは、応答の遅延、データ提供リソースへの直接メモリアクセスの欠如、およびフォールトトレランスに起因する問題のために問題があります。

この質問では、大量のデータを返すクエリの結果を処理する問題を解決するための設計パターンについて説明します。通常、これらのクエリは、1つまたは複数の中間層を持つワイドエリアネットワーク（またはインターネット）を介して、リモートサーバーにあるリレーショナルデータベースに対してクライアントプロセスによって行われます。

このソリューションには、データセットを走査し、クライアントに適切なレベルの抽象化を提供するイテレータの使用、データサブセットのダブルバッファリング、マルチスレッドデータ取得、クエリスライスなど、データ取得戦略の組み合わせの実装が含まれます。

レポート側についてはどうですか？データウェアハウスは受け入れ可能ですか、それともデータベースとビジネスそのものにビジネスロジックを組み込んでいるため、設計が悪いのでしょうか。

あなたがビジネスロジックについて話しているとは思わない、これはより多くのレポートロジックです。この画面の情報を使用してユーザーは何をしますか？それは単にステータスの更新のためですか？ドメインモデルはトランザクション操作をモデル化するために使用され、レポートは別の懸念事項です。SQL Serverからデータを取得したり、データウェアハウスに配置したりすることは、レポートのシナリオに適しています。

ドメインモデルは、プロジェクトメンバーが同じプロジェクトに同時に予約できない、または週x時間しか予約できないなど、ドメインの不変条件を適用する必要があります。または、プロジェクトが完了しているなどの理由で、このプロジェクトに予約することはできません。ドメインモデルの状態（データ）は、レポート用に個別にコピーできます。

クエリのパフォーマンスを向上させるには、マテリアライズドビューを使用できます。モデルに対して操作がコミットされると（たとえば、この人の4時間を予約するx時間）、成功すると、イベントをスローしてレポートデータベースに保存し、レポートに必要な計算を行うことができます。これで、クエリを実行するのが非常に高速になります。

トランザクションとレポートコンテキストを分離してください。ドメインモデルをレポートするためのリレーショナルデータベースは構築されませんでした。

編集

件名に関する有用なブログ投稿http://se-thinking.blogspot.se/2012/08/how-to-handle-reporting-with-domain.html

それから4年後、私はこの質問を再び見つけました。答えは何ですか。

アプリケーションとその特定のニーズに応じて、ドメイン/トランザクションデータベースとレポートは別々の「システム」または「エンジン」にすることも、1つのシステムで処理することもできます。ただし、これらは論理的に分離する必要があります。つまり、データを取得してUIに提供するさまざまな手段を使用します。

私はそれらを物理的に分離することを好みます（論理的に分離することに加えて）が、多くの場合、それらを一緒に（物理的に）開始し、アプリケーションが成熟するにつれてそれらを分離します。

どちらにしても、それらは論理的に異なるはずです。レポートシステムでビジネスロジックを複製しても構いません。重要なことは、レポートシステムがドメインシステムと同じ答えを得るということですが、チャンスは異なる方法で得られる可能性があります。たとえば、ドメインシステムには、プロシージャコードで実装された非常に厳しいビジネスルールが（おそらく）たくさんあります。レポートシステムは、データを読み込むときに同じルールを実装できますが、SETベースのコード（SQLなど）を使用して実装します。

アプリケーションのアーキテクチャの進化が、進化するにつれて現実的にどのようになるかを次に示します。

レベル1-論理的に分離されたドメインシステムとレポートシステム、ただし同じコードベースとデータベース内

レベル2-ドメインとレポートシステムを論理的に分離しましたが、現在は同期を使用してデータベースを分離しています。

レベル3-論理的および物理的に分離されたドメインとレポートシステム、および同期を使用した個別のデータベース。

主なアイデアは、レポートとドメインには根本的に異なるニーズがあるということです。異なるデータプロファイル（読み取りvs書き込みおよび更新頻度）、異なるパフォーマンス要件など。したがって、それらは異なる方法で実装する必要があり、ビジネスロジックの重複が必要になります。

ドメインとレポートシステムのビジネスロジックを互いに最新の状態に保つ方法を考案するのは、あなたのビジネス次第です。

アクティブなプロジェクトのリストを表示するには、レポート/ダッシュボードが必要です

それぞれの状態のプロジェクトは、静的として格納されるべき計算毎及びウェル形式のデータベース内の情報と任意のシミュレーションは、 WebAppのように、クライアント上で処理されるべきです。

現在の燃焼速度での予算枯渇日

このタイプの投影は、オンデマンドで実行しないでください。リソース、レート、タスク、マイルストーンなどの計算を実行するなど、要求に応じてこの情報を管理すると、将来の呼び出しでこれらの結果を再利用せずに計算レイヤーを広範囲に使用できます。

分散環境（プライベートクラウドまたはパブリッククラウド）を想像すると、計算の層、データベースの低使用率、およびキャッシュの完全な不足で莫大なコストが発生します。

これは最初にドメインを介して実行する必要がありますか？パフォーマンスはどうですか？

ソフトウェアの設計には、読み取り中ではなく「データ入力」中に必要な結果を得るために必要な計算の正規化を実行する機能を含める必要があります。このアプローチにより、コンピューティングリソースの使用が大幅に削減され、何よりも顧客によって「読み取り専用」と見なされるテーブルが作成されます。これは、強固でシンプルなキャッシングメカニズムを作成するための最初のステップです。

したがって、ソフトウェアアーキテクチャを完成させる前の最初の検索は、Distributed Cache Systemです。

（request：aggregation）！= 1：1

したがって、（最初と2番目の例の両方について）私の考慮事項は、クライアントリクエストごとの集約を減らす目的で、データを正規化するのが適切かどうかを理解することです。1つの目標が持続可能なシステムの取得である場合、1：1（要求：集約）にすることはできません。

計算をクライアントに配布します

もう1つの質問は、ソフトウェアの設計を完了する前に、クライアントのブラウザを委任したいということです。

MV * という名前でしたが、今日流行しているのは事実です。これに加えて、その目的の1つはWebApp（単一ページアプリ）を作成することです。クラウドプロバイダーに支払います。これらはクライアントで実行されます）。

したがって、私の結論は次のとおりです。

1. データの表示を実行するために実際に必要な操作の数を理解します。

2. バックグラウンドでこれらの処理を実行できる数を分析します（そして、正規化後にキャッシュシステムを介して配布できます）。

3. クライアントで実行できる操作の数を理解し、プロジェクトの構成を取得し、WebAppのビューで実行して、バックエンドで実行される計算を減らします。

クエリにキャッシュを使用し、キャッシュにドメインを使用します。

stackoverflowには「トップユーザー」と呼ばれる機能があります。トップユーザーページの下部に「コミュニティWiki以外の質問と回答のみがこれらの合計に含まれています（毎日更新）」という行があります。これは、データがキャッシュされていることを示します。

しかし、なぜ？

パフォーマンスの問題かもしれません。ドメインロジックの漏洩について同じ懸念があるかもしれません（この場合、「これらの合計には非コミュニティWikiの質問と回答のみが含まれます」）。

どうやって？

私は彼らがこれをどうやってやったのか本当にわからないので、ここに単なる推測があります:)

まず、ターゲットの質問/回答を見つける必要があります。潜在的なターゲットをすべて取得するだけで、スケジューリングタスクが機能します。

次に、1つの質問/回答のみを見てみましょう。非コミュニティウィキのものですか？30日以内ですか？ドメインモデルで答えるのは非常に簡単です。投票を数え、満足したらキャッシュします。

これでキャッシュができました。これはドメイン派生の出力です。適用されるのは単純な基準のみであるため、クエリは高速で簡単です。

結果をより「リアルタイム」にする必要がある場合はどうなりますか？

イベントが助けになるかもしれません。スケジューリングタスクでキャッシュをトリガーする代わりに、プロセスを多くのサブプロセスに分割できます。たとえば、誰かがhippoomの回答に投票すると、hippoomのトップユーザーキャッシュの更新をトリガーするイベントを公開します。この場合、頻繁にすばやく小さなタスクが発生する場合があります。

CQRSは必要ですか？

スケジューリングタスクアプローチでもイベントアプローチでもありません。ただし、cqrsには利点があります。キャッシュは通常、高度に表示指向であり、最初にいくつかのアイテムが必要でない場合、それらを計算してキャッシュしない場合があります。イベントソーシングを使用するCQRSは、イベントを再生することにより、履歴データのキャッシュを再構成するのに役立ちます。

関連する質問：
1. https://stackoverflow.com/questions/21152958/how-to-handle-summary-report-in-cqrs 2. https://stackoverflow.com/questions/19414951/how-to-use -大規模な操作を伴うリッチドメイン/ 19416703＃19416703

それが役に立てば幸い ：）

免責事項：
ドメインモデルを使用したアプリケーションについては、かなり経験がありません。
私はすべての概念を理解しており、これらの概念を作業中のアプリケーション（ドメインが豊富であるがオブジェクト指向、実際のドメインモデルなどが不足しているアプリケーション）に適用する方法について長い間考えてきました。
この質問は、私が直面した重要な問題の1つです。私はこれを解決する方法を考えていますが、先ほど言ったように...それは私が思いついたアイデアです。
実際のプロジェクトにはまだ実装していませんが、動作しない理由はわかりません。

これを明確にしたので、ここに私が思いついたものがあります-最初の例（プロジェクトメトリックス）を使用して説明します。

誰かがプロジェクトを編集すると、とにかくドメインモデルを介してそれをロードして保存します。
この瞬間に、あなたは持っているすべての、すべてのメトリックを計算するためにロードされた情報（総予算、日付などへの努力）このプロジェクトのために。

これをドメインモデルで計算し、ドメインモデルの残りの部分とともにデータベースに保存できます。
そのためProject、ドメインモデルのクラスにTotalBudgetはEffortToDateなどのプロパティがあり、ドメインモデルが格納されているデータベーステーブル（同じテーブルまたは別のテーブル... doesn）にこれらの名前の列もあります。問題ありません）。

もちろん、これを開始するときに、既存のすべてのプロジェクトの値を計算するために1回実行する必要があります。ただし、その後、ドメインモデルを介してプロジェクトが編集されるたびに、データは現在の計算値で自動的に更新されます。

したがって、何らかのレポートが必要なときはいつでも、必要なすべてのデータが既に存在し（事前計算済み）、次のようなことができます。

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

ドメインモデルが格納されているテーブルから直接データを取得するか、何らかの方法でデータを2番目のデータベース、データウェアハウスなどに抽出するかどうかは関係ありません。

1. レポートストアが実際のデータストアと異なる場合は、「ドメインモデルテーブル」からデータをコピーするだけです
2. 実際のデータストアを直接クエリする場合、データは既にそこにあり、何も計算する必要はありません。

どちらの場合でも、計算のビジネスロジックは、ドメインモデルという1つの場所にあります。
他のどこにも必要ないので、複製する必要はありません。