event-sourcing - 集合体間通信

Question

現在、集約ルートごとに 1 つのイベント ストリームと 2 つの集約ルートがRoomありRoomTypeます。

の動作は、それがRoom何であるかによって異なりRoomTypeます。両方の集計を分離するために、TheRoomTypeは集計で roomTypeId として表されRoomます。の変更はRoomType、イベントによって表されRoomTypeChangedます。

はRoomTypes個別に管理でき、別のアグリゲートにある必要があります。

ここで、次の使用例を検討してください。

ユーザーが を無効にするRoomTypeと、すべてRoomsがRoomtypeフォールバックに切り替わるはずRoomTypeです。

私はいくつかのアプローチを考えましたが、それらはすべて問題があるようです:

1. イベント リスナーに -event をリッスンさせ、それを持つすべての-aggregatesRoomTypeInvalidatedに を送信します。どうすればこれを行うことができますか？私のreadmodelにアクセスしない限り、どの集計がそれを持っているかを知る方法はありません。これは間違っているようです。すべての集約をロードする場合でも、(geteventstore を使用して) すべてのストリームのサブセットをロードできないため、そのタイプの集約のみをロードする方法はありません。SwitchToFallbackRoomTypeRoomRoomtypeRoomtype

2. RoomTypeChanged-events を集計に再適用するときは、単に適用するのではなく、まだ存在するRoomかどうかを確認しますが、どれが存在するかを確認するにはどうすればよいでしょうか(1 と同じ状況になりますが、逆になります)。 ? また、イベントの再適用にロジックを入れるのは間違っているようです。それらは状態の変化を表すだけでよいと思います。RoomTypeRoomTypes

これをどのように解決しますか？

Answer 1

部屋の種類ごとにプロセス マネージャーを使用し、部屋のリストをプロセス マネージャーのプロパティとして使用してみませんか?
サービスまたはコマンド ハンドラーから読み取りモデルをクエリしても、フレームワークの一貫性は保証されません。無効化された部屋タイプに部屋が割り当てられたが、読み取りモデルがまだ更新されていない場合はどうなりますか? （それは私が直面しているシナリオのようなものです）

Answer 2

毎回データが完全に一貫していることを確認してこの問題を解決することは、設計に反します。イベント ソーシングは、システムが最終的に整合性があると想定しているため、読み取りモデルで不整合が発生することは正常であり、予期されています。

これを解決する最善の方法は、無効化された新しい TypeId を使用してすべての部屋の読み取りモデルをクエリすることです (ソリューション 1)。これらすべてのルームを更新した後、更新されていないストラグラーがいくつかある可能性があるため、しばらくしてから (1 分としましょう)、イベント ハンドラーを再実行します。

その時点で (コマンドがルームの作成時にルーム タイプの有効性をチェックすると仮定すると)、古いルーム タイプで新しいルームを作成することは不可能であり、ストラグラーの読み取りモデルはすでに安定しているはずです。したがって、コードを再実行すると、残りのすべてが更新されます。