メッセージング (イベントの発行) をシステムに統合すること、複数のコンポーネント、いくつかの異なるスタックなどを検討しています。少数のパブリッシャーとサブスクライバーから始めて、それが理にかなっている場所を徐々に紹介します。
イベントを発行する場合、たとえば「NewProductAddedToCatalogue」というタイプで、新製品のすべての属性が含まれているか、新製品 ID または何らかの形式の残りの URL が含まれている必要があります (例: http://db.intranet/products/[uuid])。 . それぞれのアプローチの利点は何ですか? 一部のサブスクライバーは最小限の数の属性にのみ関心があると思いますが、ウェブサイトの発行者などはそれらすべて (またはほとんど) へのアクセスを希望する場合があります。どちらのアプローチにも重大な欠点はありますか?
これは、私たちの製品カタログが私たちの中核であるため、私たちが長い間議論してきた興味深いトピックです. 私たちが発見したことは、各サブスクライバーが共通のデータ セットに関心を持ち、そのデータを独自のデータで強化するということです。その一例は、消費者にわかりやすい画像と説明を追加するマーケティング サブスクライバーです。これは、身長、体重、立方体などを追加するサプライ チェーン サブスクライバーとはまったく異なります。このアプローチは、各コンポーネントが独自のデータを担当する場合に機能します。
一部のカタログが集中管理されている場合は、各サブスクライバーに共通の要素と関心のあるデータを送信するのが最も簡単であることがわかりました。データの重複をなくし、システムを分離したままにすることができます。
簡単な答えは、2 種類のイベント メッセージを公開しない理由です。
1 つは製品 ID のみの軽量イベントであり、これはサブスクライバーによって使用され、サブスクライバーはイベント データ自体を充実させます。
もう 1 つのメッセージには、データを充実させたくない消費者のために、イベントを理解するために必要なすべてのデータが含まれます。
より長い答え - 私は「軽量」イベントのアイデアがあまり好きではありません。これの問題は、基本的にイベントメッセージを「何かが変更された」通知に変えていることです。
これにより、基になるデータ変更からイベントが削除されます。たとえば、通知は何が変更されたかを示すのではなく、何かが変更されたことのみを示します。基礎となるデータが、イベントが発生したときと同じ状態ではなくなるまで、イベント メッセージが遅れている可能性は十分にあります (これが問題になるかどうかは、個々の要件によって異なります)。
ただし、さらに重要なことは、データを「強化」するためのルックアップによって、コンポーネント間の結合が導入されることです。イベント メッセージの背後にある考え方は、イベント サブスクライバーがそれを処理するだけでよいということです。サブスクライバーは、メッセージの発行元について何も知る必要はありません。 、より具体的には、メッセージの送信元のデータ ソースについてです。
ただし、いくつかの利点があります。通知タイプのメッセージ処理は本質的に冪等であるため、必要な労力が少なくて済みます。