私たちはシステム（複数のコンポーネント、いくつかの異なるスタックなど）にメッセージング（パブリッシングイベント）を統合することを検討しています。少数のパブリッシャーとサブスクライバから始め、それが意味のあるところを紹介する。メッセージング - すべての属性またはidポインタのみ
イベントを公開する場合は、「NewProductAddedToCatalogue」と入力します。新しい商品のすべての属性や、新商品IDや休憩URLの一部の形式などが含まれているとします。 http：//db.intranet/products/ [uuid]。それぞれのアプローチの利点は何ですか？私はいくつかの加入者が最小数の属性に興味を持ち、他の加入者は他の属性に興味があると感じています。ウェブサイトのパブリッシャーは、すべて（またはほとんど）それらにアクセスしたいと思うかもしれません。どちらのアプローチにも大きな欠点がありますか？
クイックアンサー - 2種類のイベントメッセージを公開してみませんか？
これは、製品IDだけの軽量イベントであり、イベントデータ自体を豊かにする購読者によって使用されます。
他のメッセージには、データを豊かにしたくない消費者のために、イベントを理解するために必要なすべてのデータが含まれています。
答えが長すぎる - 「軽量」イベントのアイデアはあまり好きではありません。この問題は、基本的にイベントメッセージを「何か変わった」通知に変えてしまうことです。
これにより、そのイベントの基になるデータ変更が削除されます。たとえば、通知では何が変更されたかは分かりませんが、何かが変更されただけです。イベントメッセージが、イベントが発生したときと同じ状態になっていないポイント（イベントの問題があなたの個々の要件に該当するかどうかに関係なく）まで遅延されている可能性があります。
さらに重要なしかし、データを「豊かに」するためのルックアップは、コンポーネント間の結合を紹介 - イベント・メッセージの背後にある考え方は、イベントの加入者がそれを処理することができるということです - 加入者がについて何を知っている必要はありません。メッセージの発行元 - より具体的には、メッセージの発信元に関する情報源。
しかし、通知タイプのメッセージ処理は本質的にidempotentなので、そこには手間がかかりません。
これは、私たちの製品カタログが弊社のコアであるため、これまで検討してきた興味深いトピックです。私たちが見いだしたことは、各加入者が共通のデータセットに関心を持ち、そのデータを独自のもので強化することです。たとえば、消費者にやさしい画像や説明を追加するマーケティングサブスクライバがその例です。これは、高さ、重量、立方体などを追加するサプライチェーンの加入者とはまったく異なります。このアプローチは、各コンポーネントが独自のデータを担当する場合に機能します。
一部のカタログが集中管理されている状況では、各サブスクライバに共通の要素と興味のあるデータを簡単に送信できることがわかりました。データに重複する部分がなく、システムを分離した状態に保つことができます。