Architecture-center: ProductsCommandHandler（CQRS）とProductRepository（従来のアーチ）の違いは何ですか？

@martinmthomasご質問ありがとうございます！ 必要に応じて、更新を確認して提供します。

@MikeWassonここで何か考えはありますか？

AB＃160217-報告していただきありがとうございます-この問題は審査中です

@martinmthomas実際、コマンドハンドラーはリポジトリではありません。 リポジトリを使用します。

コマンドハンドラは、「適切な場合、実際のコマンドを処理する」ことを目的としています。 この例では、 ProductsCommandHandlerクラスはコンストラクターでIRepository<Product>を受け取ります。

ユーザーが製品5555を4つ星に評価するとします。

• ユーザーにはインターフェースが表示されます。 Webページ（ローカルの.exeプログラムなど、Webサイトを想像してみてください）を考えてみましょう。
• ユーザーがボタンをクリックします。 これが、データ{"product":"5555","stars":4}を使用してルート/レートに移動するAJAXPOSTをトリガーするとします。
• POSTルートにはコントローラーがあります。 このコントローラーは、POST呼び出しからの「書き込み」操作に関連付けられています。
• ここでの古典的なアプローチのコントローラーは、古典的な製品リポジトリをロードし、製品5555をロードするだけです。次に、製品に「4つ星の評価が付けられました」と伝えて保存します。
• このアプローチでは、コントローラーはコマンドRateProductを作成し、製品5555、星4を入力します。この例では、誰が評価しているかも入力します。
• この時点で、コントローラーは書き込みモデルに「コマンドを送信」し​​ます。 ここには2つのオプションがあります。コマンドハンドラーを呼び出すか、キューに入れます。
• キューがないとします。 次に、コントローラーでCommandHandlerを取得し（おそらく依存性注入によって）、そこにコマンドを配置するだけです。h.Handle（c）; ここで、cはRateProductコマンドです。
• キューがあるとします。 次に、（おそらく依存性注入によって）コントローラーにキューを取得し、そこにコマンドをエンキューします。q.Queue（c）;
• この最後のケースでは、キューのリスナーがコマンドをキューから取り出し、代わりにコマンドハンドラーを呼び出します。
• 3番目のオプション（推奨）として、コントローラーはコマンドが同期的に処理されるか（ハンドラーを取得する）、非同期的に処理されるか（キューを取得する）を選択しませんが、コマンドがコマンドバスを使用する「一般的なアプローチ」を使用する必要があります配置されます。 コマンドバスがbであるとすると、b.Send（c）;を実行します。 ここで、cはRateProductコマンドです。
• この3番目のアプローチでは、コマンドハンドラーをバスの最後に配置し、「バスからコマンドを取り出してキューに配置する」ようにミドルウェアを構成できます。

したがって、3つのオプション：a）ハンドラーを取得する、b）キューを取得する、c）バスを取得し、コマンドをハンドラーまたはキューに送信することを決定させます。

どのようなアプローチをとっても...「従来のリポジトリ」の主な違いは、コントローラでリポジトリ自体を呼び出さないことです。 コントローラは「エンティティの管理方法」（従来のリポジトリ）を認識していませんが、「エンティティに対して行うことの意図を管理する方法」（コマンドハンドラ）を認識しています。

次に、インテントとして送信されたのは、その名前が示すように、どこか（html Webコントローラー、APIコントローラー、コマンドラインなど）から送信された「コマンドを処理する」コマンドハンドラーであり、CommandHandlerです。 （書き込み側に属します）そのコマンドをどうするかを決定します。

たとえば、CommandHandlerはリポジトリを使用して製品を取得し、状態を設定して保存できますが（例のように）、イベントログに書き込んだり、要素をトリガーして読み取り側を更新したり、外部コネクタをトリガーしたりすることもできます。

製品とそのコントローラーを、主演/評価システムが配置または保存されている「場所」を不可知論的に評価するためのユーザーのタスクベースのUI。 システムを最初から設計し、Productクラスに例のようにRateProduct（）メソッドがすでに含まれているとします。 良い。

しかし...製品への「古い」アプローチを備えたレガシーシステムがある場合はどうでしょうか。 「モデル」（つまり、ビジネスマインド）には、製品の「評価」はありません。 代わりに、マーケティング担当者は既存の製品に評価を「追加」したいと考えていますが、すべての会社はこれが「外部のもの」であることに同意しています。 製品リポジトリを使用しますか？ または、別のヘルパーストレージを使用して、すでに機能し、十分にテストされたProductおよびProductRepositoryに「触れない」ようにしますか？

コマンドを使用する場合は、書き込みコントローラーを気にしません。 Web、API、およびCLIはすべて、「コマンド」をコマンドハンドラーに（直接、キューを介して、またはハンドラーまたはキューに順番にルーティングするコマンドバスを介して）送信するだけで、忘れてしまいます。 次に、コマンドハンドラーは、ソースコードの集中化された小さなポイントで「RateProductCommand」をどのように処理するかを決定します。これにより、これを処理する方法がアプリケーションコードから切り離され、保守性が向上します。

次に、ハンドラーは、ProductRepositoryまたはその他のアプローチを使用して「製品の評価」を保存するのが適切かどうかを判断します。

だから、答えるために：

CommandHandler =>エンティティとは何の関係もありません。 これは「ユーザーの意図」を処理します（最終的にはエンティティを変更する可能性があるため、おそらくコマンドハンドラーはリポジトリを使用します）。
リポジトリ=>特定のエンティティの実際のストレージ。

助けてくれることを願っています。
シャビ。

@xmonteroが述べたように、ProductsCommandHandlerとProductRepositoryには「has」関係しかありません。 ProductsCommandHandlerは、ProductApi / ControllerとProductRepositoryの間のインターフェイスとして機能します。 この実装は、コマンドをクエリから分離しておくのに役立ちます。 従来のアプローチでは、コマンドとクエリを一緒に実行し続けるコントローラーからのリポジトリを直接使用するため、間に他のインターフェイスは必要ありません。

コマンドをクエリから分離したままにしておくと、アプリケーションにCQRSデザインパターンが適用されます。 記事に記載されているCQRSのすべての利点を得る方向に進みます。