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