私のCQRSアーキテクチャでは、InsertSettingCommand（設定はキー/値オブジェクト）を送信するときに、キーがデータベースにまだ存在しないことを確認したいことを検証したいと思います。CQRSと検証をよく理解している場合、検証は、電子メールが構文を尊重していることや顧客の名前が空でないことを確認するなど、フォーマットに関するものを検証する場合にのみ、クライアント側で実行する必要があると言われています。しかし、私の場合、データベースにクエリを実行してデータベースが存在するかどうかを確認する必要がありますが、クライアント側の読み取りストアにクエリを実行するのが正しいかどうかわかりません。または、ドメイン側の読み取りストアに電話する必要がありますか？次に、InsertSettingDuplicatedイベントをスローしますか？
では、CQRS環境での私の状況を取り入れるための最良のアプローチは何ですか？一部の人々は補償行動について話しますか？それは私を助けることができるものですか？
ありがとう。
一意性を検証するために、クライアント側からストレージを読み取るためのクエリを実行しても問題ありません。これは、CQRSを使用したセットベースの検証に関するGregYoungの考えです。
理論的には、重複するキーをチェックする必要はありません。クライアント側は、ユーザー入力から完全にセグメント化された、そのような情報を独自に取得するように接続する必要があります。例：ドロップダウンにそのようなアイテムのリスト、またはその他の選択リストを表示します。
補償アクションまたは補償コマンドは、システムがプロセスの実行に失敗した場合にのみ使用する必要があります。したがって、いくつかのコマンドまたはビルドで実行したすべてのコマンドを障害点までロールバックする必要があります。
たとえば、システムが設定を挿入する必要があるとします。このコマンドで発生できるイベントは、「SettingInsertedEvent」のようなものだけです。したがって、このイベントが発生しなかったと仮定すると、これを補正するようにシステムに指示し、そのプロセス内で実行したすべてのことをロールバックできます。
コマンドは、dataManagerを介してチェックを行うインターフェースを実装することもできます。または、キーなしでdataModelを構築し、テーブルを自動インクリメントして、シナリオを完全に心配する必要がないようにすることもできます。（dataModelは、データベースサーバー内の既存のテーブルの単なるコード表現であり、最新のアプリケーションのもう1つの基本的な部分であるORMによってリンクされていることをご存知でしょう。）