MVC3、EF、DDDアプローチを使用するレポート/解析Webアプリケーションを作成しようとしています。私は、既存のデータベース上の集約されたテーブルのエンティティまたはオブジェクトクラスを考え出すのは難しいです。たとえば、私はOrdersとOrderLineを集計として、CustomersはEntityとして顧客を持っています。この3つのオブジェクトは、DDDアプローチを使用してモデル化することができますが、顧客名、支払いタイプなどのすべての詳細をcontatinsするOrdersAggregateテーブルを用意したい場合はどうすればいいですか？DDDレポートシナリオ
ここでは、あなたのSQLクエリを作成して関連テーブルに参加させることができますか？私はここでパフォーマンスについて心配しています。これはクラウド上で解散され、膨大な量のトランザクションが待ち受けています。
提案がありますか？
私は、この目的のためにDTOクラスを作成し、ジョインとリレーションシップを使ってSQLコマンド（手作り）から返されたデータセットを使用して記入することを提案します。
私はこのアプローチを同様の問題に使用しているため、示唆に過ぎません。
いくつかの点でCQRSとhereを利用すると、読み込みモデルと書き込みを区別することができます。
読み取りモデルを書き込みモデルとサービスから分離するだけでは、読み取りモデルが書き込みと解析の目的でカスタマイズされたDTOをフラットにし、書き込みモデルでは強力なドメインモデルを送信しますビジネスロジック処理用
しかしこれはまだジョインズの権利をしますか？またはあなたのDTOが先にフェッチされたデータをキャッシュしていますか？ – gnaungayan
要求に応じてフェッチしたり結合したりするには、2つの方法があります。キャッシュを作成するのが最適ですが、クエリのカスタマイズされたテーブル（フラット）で別のデータベースを作成し、状態を変更してデータを平坦化してクエリデータベースに格納するハンドラ –
OrderAggregateテーブルがモデルクラスに登録されますか？またはこれは私のDTOとして機能するでしょうか？ – gnaungayan
私の経験では、統計など、DDDが報告を行うに適していないことであるジミー・ニルソンなどに 一部の専門家は、通常のdataaccesであなたのドメインをバイパスすることを示しています。 これについて考えてみると、データを提示するにはドメインロジックがあまりありません。それは単にビューデータのためにORM、リポジトリ、aggregaterootsなどでレイヤーとDDDスタイルを行う際のオーバーヘッドのように思えます。
個人的な意見です。 /幸運にもMagnus
私はこれも同様に考えていますが、私はプロジェクト全体でEFを利用したい – gnaungayan