問題タブ [command-query-separation]

2 つの WCF サービスを呼び出す WPF クライアントがあります。

1 つのサービスはクエリ専用で、もう 1 つのサービスはコマンド用です ( CQS パターン)。

コマンド サービスを呼び出すにはどうすればよいですか?

コマンド サービスのすべての操作は、値を返してはならないため、「一方向」でなければならないことをどこかで読みました。何か問題が発生した場合、操作はクライアントに「FaultException」をスローする必要があります。

しかし、コマンドがすべて一方向の場合、クライアントで何をすればよいでしょうか?

WPF クライアントに「AddProduct」ウィンドウがあり、情報を入力して「保存」を押したとします。

サービスで「AddProduct(Product)」を呼び出すようになりましたが、次のようになります。

1. ウィンドウを閉じる必要がありますか？
2. FaultException がないかどうかを確認するために 10 秒間待機する必要がありますか?
3. 操作は「一方向」であってはなりませんか? もしそうなら - コマンドサービスのすべての操作は、「成功」または「失敗」を伴う何らかのタイプの一般的な「結果」オブジェクトを返す必要がありますか?
4. セクション 3 が「はい」の場合 - 別のスレッドでサービスを呼び出し、サービスから応答が返るまでウィンドウのすべてのコントロールを「無効」にする必要がありますか?

ありがとう。

私のさまざまなプロジェクトでは、コマンド/クエリ分離パターンを実装し、NHibernate を ORM として使用しています。

一般に、コマンドとクエリはUserManagement、TagManagement、QuestionManagementなどの特定の一連のアクティビティに関連する別のプロジェクトに保持します。

簡単に見つけられる機能を備えたこれらのリポジトリにすべてをうまく分割するのがとても好きです。このように物事を行うことには確かに利点があります。

しかし、特に NHibernate がすでにそのような強力な抽象化を提供していることを考えると、基本的なクエリに対するこの抽象化の価値について疑問に思い始めています。

私のMVCコントローラーでこれを考慮してください：

これをリポジトリのクエリに抽象化できましたUserManagementが、それがどのような価値を提供するのかわかりません。

どう思いますか？すべてをコマンド/クエリ パラダイム内に保持しますか?それとも、このような単純な要求のためにコントローラで nhibernate セッションを直接使用しますか?

コマンドとクエリの分離は、「すべてのメソッドは、アクションを実行するコマンドか、呼び出し元にデータを返すクエリのいずれかである必要があるが、両方であってはならないことを示しています。つまり、質問をしても答えが変わるべきではありません。」

ここで、Ruby では、popコマンドは項目が配列からポップされて返されます。

これは 1 つのメソッド内のコマンドとクエリの例であり、そうする必要があるようです。

この場合、本質的にコマンドであると同時にクエリでもあるメソッドを持つことは、本当にコードの匂いでしょうか?

(設計の 1 つの側面として) CQS を使用して新しいプロジェクトを開始しますが、CQRS + イベント ソーシング、イベント ストリーミング、または履歴モデリングは使用しません。少数のデータ セットを使用する多数のユーザーがいる (そしてユーザーをブロックしたくない) 状況に遭遇した場合は、イベント ソーシングを実装します。これが意味すること (少なくとも私にとって) は、コマンドをクエリから分離すること (関心の分離) から始めることだけです。

コマンド側には EF ORM と実際のスキーマを使用しています。クエリ側では、(私が読んでいるものから) ビューのみを使用するのが最善ですが、この意見は、ORM を使用する (または使用しない)、および/またはレポ、または ADO.NET + ストアド プロシージャを排除しないと思います。など、DBからこれらのビューにアクセスする方法として（私は思う）。

これは、私が考えていることを大まかに説明するために作成した図です（決して包括的ではありません）。

私の質問：

パート 1: データベースから (ビュー) を使用し、ViewModel (DTO) を使用してクライアントに何らかの状態の新しいビューを提供します (コマンド側への呼び出し後)。

パート 2: タスク ベースの Web UI を変更し、UI の基礎となる ViewModel を変更した後、ViewModel がコマンド側のエンティティ (ドメイン モデル) から完全に分離されている場合、これからコマンドを発行するにはどうすればよいですか? . これらの ViewModel (DTO) は、エンティティとはまったく異なる "形状" である可能性があります。

更新：

明確にするために、私は非同期を使用するつもりはなく、トランザクションは開始するのにプラスです。これはコマンドとクエリの分離のみです（コマンド側が「無効」のみを返す完全なCQRSではありません）-私は探していますここで非常に基本。また、これまで読んだことから、DDD と境界コンテキストは CQRS と密接に関連しているように見えます。この時点で、境界コンテキストとともに DDD または集約ルートを実際に使用した経験はありません。この方法論/パターンに取り組むための現実的かつ差し迫った必要性。現時点では、コマンド側に EF/Migrations を使用する予定のようですが、クエリ側で何を使用するかはまだ決めていません (ADO.NET を検討中です)。

私の場合、コマンド側はオブジェクトを返します。たとえば、データベースで生成された CustomerId を持つ新しい Customer です。コマンドとクエリの両方に 1 つのデータベースを使用し、クエリからモデルを返すために DB にビルドされたビューを使用したいと考えています (つまり、ほとんどの場合、クエリをビューに "マップ" したいと考えています)。 . 私が知らないのは、クエリ側を使用してコマンド側のデータを返す場合、オブジェクトを返す必要がある場合にコマンドがどのように見えるかです。MVC の場合、オブジェクトを ViewModel に変換する Automapper を組み込んでみます。

学習目的でスケーラビリティの高い Web サイトに取り組んでいます。CQS パターンと CQRS のいくつかのアイデアを使用することにしました。システムがメッセージ バス (2 つの別個のメッセージ バス) から送受信するコマンド ハンドラーとイベント ハンドラーによって使用される、個別の書き込みレイヤーと読み取りレイヤーがあります。

コマンドの処理に問題があります。そのコマンドは何も返してはならないことを読みました。ポイントは、たとえば、ユーザーがイベントを作成したり、プロフィールの何か (写真や名前) を変更したりできるフォームを持っていることです。ユーザーが保存をクリックした後、彼、彼のプロフィールを表示したり、新しいイベントを彼の壁に追加したりします。しかし、コマンドがバスにのみ送信されている場合、彼のプロファイルが既に更新されていることをどのように知ることができますか? I コマンドと CRUD 操作のアイデアをどのように結び付けるのですか? それとも、この間違った考えはまったくありませんか？

ドメイン イベント パターンとこの投稿を考慮して、トランザクション モデルごとに 1 つの集計を保持することを人々が推奨するのはなぜでしょうか? 1 つの集計が別の集計の状態を変更できる場合があります。集約を削除 (またはその ID を変更) しても、それを参照する他の集約の状態が変更されます。集約ごとに 1 つのトランザクションを維持するとスケーラビリティーが向上する (サーバーごとに 1 つの集約を維持する) と言う人もいます。しかし、この種の考え方は、DDD の基本的な特徴であるテクノロジにとらわれないという特徴を壊しているのではないでしょうか。

したがって、上記のステートメントとあなたの経験に基づいて、他の集計の変更につながる集計、ドメインイベントを設計するのは悪いことですか?これにより、トランザクションごとに2つ以上の集計が行われます(例: 新しい注文が行われたとき) 100 個のアイテムを使用すると、顧客の状態が通常から VIP に変わります)?

このSpring MVCアプリケーションからコードを読みました:

https://github.com/spring-guides/tut-rest/tree/master/6/complete/src/main/java/com/yummynoodlebar/core/events

イベントフォルダーからのこれらのクラスの役割がわかりません。アプリケーションの別の場所でそのようなイベントをキャッチするにはどうすればよいですか?

このアプリケーションで私が理解できないもう 1 つのことは、サービス レイヤーのどこかでコマンドとクエリの分離を使用しない理由です。彼らは残りのコントローラーで CQS を使用しました。私はそれに同意しません。代わりに、サービス層で CQS を使用して、検証やその他のコア操作をサービスに追加する簡単な方法を提供する必要があります。このリンクは、サービス層での CQS 分離について私が話していることを説明しています。

上記のリンクで説明されている CQS パターンを実装する方法について提案がある場合は、それを教えてください。