3

私は現在、特定のシステムを構築するときに CQRS を適用できるかどうかを調査しており、簡単に答えを見つけることができないいくつかの質問があります。

CQRS コマンドは、ユーザー アクションに応答するために使用されます。ユーザーは UI を介して必要なアクションを選択し、UI レイヤーはそれらを処理するコマンドを認識します。

ただし、ユーザーの役割、エンティティのビジネス状態 (パブリック、アーカイブ済み)、エンティティとユーザーの関係 (たとえば、チケットにレポーターと担当者が割り当てられているなど) などのコンテキストに基づいて、コマンドが有効でない場合があります。

コマンドは、全体的な検証の一部としてこれを確認できます。コマンドが特定のエンティティ状態に対して有効でない場合、変更を加えるべきではないことは明らかです。したがって、該当する場合は、検証と変更をトランザクションにラップする必要があります。

これはすべて適切で必要なことですが、コマンドが UI レイヤー内で有効かどうかを知る必要があります (文脈上、ここでは完全な検証は気にしません)。そのため、ボタンやメニュー項目などの適切な UI 要素は、該当しません。したがって、詳細/更新ビューの読み取りモデルは、有効なコマンドのリストを返す必要があるようです。また、エンティティを一覧表示する読み取りモデルがある場合、ここでも同様のセキュリティ トリミングが必要で、同じルールとコードを使用します。

おまけとして、一部のエンティティは時間に依存する状態を持っているため、モデルに保存することはできませんが、現在のサーバー時間を使用して実行時に決定する必要があります。

読み取りモデルがそのような情報を格納できないという事実も、コンテキストなしでは知ることができないため明らかです。

DRY に違反することなく (ビジネス ロジックを複製しないように) ユーザー フレンドリーでクリーンな方法でこれを処理するには、コンテキストとビジネス状態のチェックに基づいて追加のクエリ条件を追加し、有効なリストを追加することで、ここで CQRS を少し曲げる必要があります。コマンドは読み取りモデル内にあるため、これらのシステムの側面はあまり分離されなくなり、読み取りモデルを返すプロセスにはコマンド ハンドラーが関与します

おそらく私はここで心配しすぎており、セキュリティ トリミングが分野横断的な懸念によって CQRS の原則に違反することを許してしまうのでしょうか?

4

1 に答える 1

1

あなたの基本的な仮定は正しいです。成功する可能性が非常に高い場合にのみ、コマンドをアプリケーションに送信する必要があります。特定の UI で有効なコマンドのみを使用できるようにする必要があり、基本的なクライアント側の検証も行う必要があります。

センコンの質問について: 時間が経過したときにドメイン モデルの状態が変化した場合、これらの変化はドメイン イベントであり、プロジェクションによって明示的にモデル化および処理して、それに応じて読み取りモデルを更新することができます。

于 2012-08-31T19:53:01.680 に答える