我們正在考慮在我們的系統中集成消息傳遞（發佈事件），我們有多個組件，幾個不同的堆棧等等。我們將從少數發佈者和訂閱者開始逐步介紹它的意義。消息傳遞 - 所有屬性或只是一個ID指針
如果我們發佈了一個事件，比如說類型：'NewProductAddedToCatalogue'，它應該包含新產品的所有屬性還是隻包含新產品ID或某種形式的休息URL HTTP：//db.intranet/products/ [UUID]。每種方法的優點是什麼？我覺得有些訂閱者只會對最少的屬性感興趣，而其他的網站發佈者可能想要全部（或大部分）訪問它們。兩種方法都有什麼重大缺點？
快速回答 - 爲什麼不發佈兩種類型的事件消息？
一個可能是一個只有產品ID的輕量級事件，這將由訂戶使用，然後這些訂戶將自己豐富事件數據。
其他消息將包含需要了解事件的所有數據，以供不想豐富數據的消費者使用。
更長的答案 - 我不太喜歡「輕量級」活動的想法。問題在於你基本上把你的事件信息變成了「改變了事情」的通知。
這從它的底層數據變化的情況下 - 例如通知沒有說發生了什麼變化，而只是說事情已經改變。這是完全有可能的事件消息可能已被延遲到底層數據不再處於相同的狀態時一樣，引發事件（你是到您的個性化需求，這是否是一個問題）點。然而，「豐富」數據的查找引入了組件之間的耦合 - 事件消息背後的想法是事件訂閱者可以處理它 - 訂閱者不需要知道任何有關消息的發佈者 - 或者更具體地說，關於消息來自的數據源。
不過，也有一些好處 - 通知類型的消息處理是idempotent天生所以有介入有較少的努力。
這是我們詳細討論了一個有趣的話題，因爲我們的產品目錄是我們的核心。我們發現每個訂閱者都會對一組共同的數據感興趣，然後用它自己的數據來增強這些數據。其中的一個例子就是市場營銷用戶可以添加用戶友好的圖像和描述。這與供應鏈訂戶完全不同，後者會添加諸如身高，體重和立方體之類的東西。這種方法在每個組件負責其自己的數據時都有效。
如果您處於您的某些目錄集中管理的情況，我們發現它最容易向每個訂閱者發送常見元素以及它感興趣的數據。我們發現真的沒有數據中存在大量重疊，並且可以保持系統的解耦。