問題タブ [integration-patterns]

私たちは現在、ある中央アプリケーションから関心のある可能性のある他のコンシューマ アプリケーションにイベントをブロードキャストし始めています。また、公開されたメッセージにどれだけ入れるかについて、チームのメンバー間でさまざまなオプションがあります。

一般的なアイデア/アーキテクチャは次のとおりです。

• プロデューサー アプリケーションで:
  • ユーザーは、作成/変更/削除できるいくつかのエンティティ (DDD の意味での集約ルート) と対話します
  • 何が起こっているかに基づいて、ドメイン イベントが発生します (例: EntityXCreated、EntityYDeleted、EntityZTransferred など...つまり、CRUD だけでなく、ほとんどの場合)。
  • 発生したイベントは、RabbitMQ Exchange に送信するメッセージに変換/変換されます
• RabbitMQ で(RabbitMQ を使用していますが、問題は実際にはテクノロジーに依存しないと思います) :
  • 消費するアプリケーションごとにキューを定義します
  • バインディングは交換をコンシューマ キューに接続します (おそらくメッセージ フィルタリングを使用)
• 消費するアプリケーションで
  • アプリケーションはそのキューからメッセージを消費して処理します

Enterprise Integration Patternsに基づいて、公開されたメッセージのCanonical 形式を定義しようとしていますが、次の 2 つのアプローチの間で迷っています。

1. 最小限のメッセージ/ event-store-ish : ドメイン モデルによって公開された各イベントについて、関連する集約ルートの部分のみを含むメッセージを生成します (たとえば、更新が行われると、更新されたセクションに関する情報のみを公開します)。集約ルートの

   • 長所

     • 小さなメッセージサイズ
     • 非常に特殊なメッセージ タイプ
     • 「ドメインイベント」の近く

   • 短所

     • 配信順序が保証されていない場合に問題があります (つまり、Create メッセージの前に Update メッセージを受信した場合はどうなるでしょうか?)
     • 消費者は、サブスクライブするメッセージの種類を知る必要があります (おそらく大きなリスト/ドメインの知識が必要です)
     • コンシューマの状態とプロデューサの状態が同期しなくなったら?
     • 将来登録するが、過去のすべてのイベントの知識を持っていない新しいコンシューマーを処理する方法

2. 完全に包含された冪等のようなメッセージ: ドメイン モデルによって公開された各イベントに対して、その時点での集約ルートの完全なスナップショットを含むメッセージを生成するため、実際には「作成または更新」と「更新」の 2 種類のメッセージのみを処理します。 「削除」 (+必要に応じてより具体的な情報を含むメタデータ)

   • 長所

     • べき等 (「これが真実のようなものです。できる限り自分自身を同期させてください」という宣言的なメッセージ)
     • 維持/処理するメッセージ形式の数が少ない
     • コンシューマーの同期エラーを段階的に修正できるようにする
     • コンシューマーは、結果のメッセージが正規のデータ モデルに従っている限り、新しいドメイン イベントを自動的に処理します。

   • 短所

     • より大きなメッセージ ペイロード
     • 純度の低い

他の方法よりもアプローチをお勧めしますか?

考慮すべき別のアプローチはありますか？