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