我们正在考虑在我们的系统中集成消息传递（发布事件），我们有多个组件，几个不同的堆栈等等。我们将从少数发布者和订阅者开始逐步介绍它的意义。消息传递 - 所有属性或只是一个ID指针
如果我们发布了一个事件，比如说类型：'NewProductAddedToCatalogue'，它应该包含新产品的所有属性还是只包含新产品ID或某种形式的休息URL HTTP：//db.intranet/products/ [UUID]。每种方法的优点是什么？我觉得有些订阅者只会对最少的属性感兴趣，而其他的网站发布者可能想要全部（或大部分）访问它们。两种方法都有什么重大缺点？
快速回答 - 为什么不发布两种类型的事件消息？
一个可能是一个只有产品ID的轻量级事件，这将由订户使用，然后这些订户将自己丰富事件数据。
其他消息将包含需要了解事件的所有数据，以供不想丰富数据的消费者使用。
更长的答案 - 我不太喜欢“轻量级”活动的想法。问题在于你基本上把你的事件信息变成了“改变了事情”的通知。
这从它的底层数据变化的情况下 - 例如通知没有说发生了什么变化，而只是说事情已经改变。这是完全有可能的事件消息可能已被延迟到底层数据不再处于相同的状态时一样，引发事件（你是到您的个性化需求，这是否是一个问题）点。然而，“丰富”数据的查找引入了组件之间的耦合 - 事件消息背后的想法是事件订阅者可以处理它 - 订阅者不需要知道任何有关消息的发布者 - 或者更具体地说，关于消息来自的数据源。
不过，也有一些好处 - 通知类型的消息处理是idempotent天生所以有介入有较少的努力。
这是我们详细讨论了一个有趣的话题，因为我们的产品目录是我们的核心。我们发现每个订阅者都会对一组共同的数据感兴趣，然后用它自己的数据来增强这些数据。其中的一个例子就是市场营销用户可以添加用户友好的图像和描述。这与供应链订户完全不同，后者会添加诸如身高，体重和立方体之类的东西。这种方法在每个组件负责其自己的数据时都有效。
如果您处于您的某些目录集中管理的情况，我们发现它最容易向每个订阅者发送常见元素以及它感兴趣的数据。我们发现真的没有数据中存在大量重叠，并且可以保持系统的解耦。