cqrs - JOliviers の CommonDomain と EventStore を使用して集計のリストを取得するには?

Question

CommonDomain のリポジトリは、「GetById()」のみを公開します。たとえば、ハンドラーが顧客のリストを必要とする場合はどうすればよいでしょうか?

Answer 1

質問の額面では、複数のアグリゲートで操作を実行する必要がある場合は、コマンドで各アグリゲートのID（クライアントがクエリ側から取得する）を指定するだけで、リポジトリから各アグリゲートを取得します。

ただし、別の回答に対するコメントの1つを見ると、実際に参照しているのはセットベースの検証であることがわかります。

この質問は、これを行う方法についてかなり多くの議論を引き起こし、GregYoungはそれにブログ投稿を書いています。

古典的な質問は、「CreateUserCommand」を処理するときにユーザー名がまだ使用されていないことを確認するにはどうすればよいですか。提案されたアプローチは、クライアントがコマンドを発行する前にクエリ側に問い合わせることによって、このチェックをすでに実行していると想定することだと思います。ユーザーアグリゲートが作成されると、UserCreatedEventが発生し、クエリ側で処理されます。ここで、挿入クエリは失敗し（DBのチェックまたは一意の制約のため）、補正コマンドが発行されます。これにより、新しく作成された集計が削除され、ユーザー名が既に使用されていることをユーザーにメールで通知する可能性があります。

重要な点は、クライアントがチェックを行ったと想定しているということです。これは最初は理解するのが難しいアプローチであることを私は知っていますが、それは結果整合性の性質です。

また、同様であり、 UdiDahanからのいくつかの賢明な言葉が含まれているこの他の質問を読みたいと思うかもしれません。

Answer 2

従来のイベント ソーシング モデルでは、get all customers などのクエリは、ドメイン内のすべてのイベントをリッスンし、関連する質問を満たすクエリ モデルを構築する別のクエリ ハンドラーによって実行されます。

たとえば、姓で顧客をクエリする必要がある場合は、すべての顧客作成イベントと顧客名変更イベントをリッスンし、姓と顧客 ID のペアの 1 つのテーブルを更新するだけで済みます。データを表示している UI に関連するその他の情報を保持することも、単に ID を保持して、関連する顧客のリポジトリに移動して、さらに作業を進めることもできます。

Answer 3

コマンドには、操作対象の集約ルートの ID が含まれている必要があります。この ID は、readmodel のビューを使用してコマンドを送信するクライアントによって検索されます。このビューには、AR が発行するイベントからのデータが取り込まれます。

Answer 4

ハンドラーに顧客のリストは必要ありません。各集計は、独自のトランザクションで処理する必要があります。このリストをユーザーに表示したい場合は、適切なビューを構築するだけです。