CQRSクエリ側の実装

Question

は、私は、ATM、私は次のアーキテクチャを持って、どこのアプリケーションのクエリ側を実装する少し混乱しています：

Product.UI.Web.Admin (MVC) 
Product.Application 
-CommandHandlers (e.g OrdersCommandHandler) 
-Commands (e.g CreateOrder) 
Product.Domain 
-Model (Behavior-rich models/repository interfaces) 
Product.Infrastructure (Base interfaces/classes) 
Product.Persistence 
-ReadModel (EF Generated models) 
--Implementation (Repository implementations: FindByID/Save) 

1. 私はProduct.Applicationでクエリの名前空間を配置する必要があり、彼らは直接データベースにアクセスする必要がありますそこから？ （UI < = Product.Application < =データベース）
2. 新しいアセンブリProduct.QueriesとProduct.UI.Web.Adminを直接作成する必要がありますか？ （UI < = Product.Queries）
3. Product.Applicationにクエリの名前空間を追加し、新しいアセンブリProduct.Reportingを作成して、アプリケーションアセンブリがクエリの名前空間でレポートアセンブリを使用するようにしますか？ （UI < = Product.Application.Queries < = Product.Reporting）

は、すべての3つのソリューションは、UIへのDTOを返します。結果を構築するためにクエリでドメインサービスを使用して簡単になるよう

は、私は解決策＃3考えていますし、またそれは、エンティティをADO.Netを使用して実装することができるデータアクセスとしてProduct.Reportingを使用します。フレームワークまたはNHibernate。または、私は何かを誤解したかもしれません。

私を案内して、それをクリアするのを手伝ってください、ありがとうございます。

更新 私は4番目の変種に来ました。 Product.Infrastructure.Queriesアセンブリを作成し

1. 、そこに私は、データベース（dbcotnext）& ReadModel（EF生成されたモデル& 一般的なクエリインターフェース）名前空間を持っています。
2. 追加Product.ApplicationでのDataModel名前空間、そこに私がUI
にProduct.Applicationで
3. 追加クエリ名前空間を返すためのDTOを持って、そこに私は、一般的なクエリを実行し、データを取得するためにdbcontext使用、のDTOにマッピングし、 UIに戻ります。

Answer 1

私はちょうど依存性の逆転原理をここに適用し、インタフェースを定義するApplication.Queriesとこれらのインタフェースを実装するInfrastructure.Queriesのようなものを持っていると思います。しかし、インフラストラクチャに関する懸念も直接Applicationレイヤーに見られました。例えば、これはヴォーン・ヴァーノンがSaasOvation協同組合BCのcom.saasovation.collaboration.application.calendarCalendarEntryQueryServiceで行ったことです。結果を構築するためにクエリでドメインサービスを使用して簡単になり、また、それはADO.Net、Entity Frameworkのかを用いて実現することができるデータアクセスとしてProduct.Reportingを使用するように私は、溶液＃3考えています

Answer 2

NHibernate。または、私は何かを誤解したかもしれません。

はい私はあなたも何か誤解していると思います。

まず、ドメインサービスについて説明しましょう： 複数のエンティティを含むドメインコンセプトを持っていても、どちらのエンティティがビヘイビアを「所有しているか」がわからない場合は です。それらのいずれにも属していないように見えます。この考え方は、ドメインサービスの必要性を示す強い の指標です。 cqrsを使用している場合、ドメイン側のサービスはコマンド側に存在するため、クエリ側はドメインサービスにアクセスできません。実際にはクエリ側がビジネスロジックを実行しないため、ドメインサービスを必要としません。コマンド側とクエリ側は完全に独立していることを忘れないでください。

CQRSのもう一つの重要な特徴は、ReadModelがADO.NetやマイクロORMのような低レベルのデータアクセス技術を使用し、レポートを生成するために腐敗したテーブルを照会することです。このアイデアのすべてがパフォーマンス上の考慮事項です。将来的にはコマンドとクエリの側面を2つの別々のインスタンスで起動することもできます。