Architecture 每个事件生成器一个主题，而多个生成器消息传递体系结构共享一个主题

这是一个有点普遍性的问题，因为它不仅适用于我的场景（使用Azure Service Bus），而且适用于发布/订阅服务器与事件上下文中的任何事件总线

问题是：是否倾向于采用一种体系结构/拓扑结构，在这种结构/拓扑结构中，主题不能在制作者之间共享？ 换句话说：每个事件制作人一个主题，而多个制作人共享一个主题

我有一个明确的偏好：一个主题只能由一个制作人拥有和访问，如果是其他制作人的话。但我似乎是团队中唯一持这种观点的人，而其他人似乎在不同的活动制作人之间“为了简单”分享同一主题方面没有任何问题，而且我也无法就技术可行性进行真正的争论

我希望从更技术的角度找到有价值的答案和良好的实践，因为我的推理是从更商业/组织的角度出发的，因为我来自DDD背景，而其他人则不是

• 主题是一对多通信的输出框（我将其解释为一个事件发布者、多个订阅者）
• 一个主题可以处理不同类型的事件消息，只要它们以某种方式相关（当然，这是非常相对的）
• 在DDD中，有一个有界上下文的概念，我喜欢将微服务/模块视为实现这些有界上下文的一种方式。因此，即使其他一些服务“认为”它们想要发布相关的内容，并且想要访问共享主题进行发布，我认为它们属于不同的有界上下文，它们应该有自己的主题
• 如果多个生产者确实属于相同的有界上下文，那么我认为只有一个服务（或infra模块）负责发布在有界上下文中发生的事件
• 一个制作者可能也想使用来自其他制作者的事件（它也是一个订阅者）。制作人订阅同一主题，并且必须根据消息是由自己还是他人生成来区分消息，这是没有意义的

如您所见，从DDD ish的角度来看，需要在同一主题中发布的多个制作人会触发设计气味。我并不是说这是不可能的，我只是想从技术的角度找出是否应该避免

有人在这方面有实际经验吗

PS：有，但我不认为这与卡夫卡对出版商和订阅者使用不同的技术方法完全相同

---

---

更新1：我不知道NServiceBus，但我与MassTransit有过一些合作，并且在利用拓扑创建MassTransit时（这是afaik的唯一方法），它不仅为每个制作人，而且为每个消息类型创建了不同的主题。

只是为了补充一些原因，我认为我们应该尽可能多地为每个制作人使用一个主题：

• 如果多个生产者将同一事件发布到同一主题，则该事件没有明确的所有权和权限。这与您在有界上下文上的观点类似
• 当多个生产者发布同一事件时，会在这些生产者之间创建事件模式的耦合。现在，事件模式不能在不同时影响所有生产者的情况下发展。这些生产者可以使用事件模式版本控制，但当多个生产者更新同一事件模式（并生成不同版本的事件模式）时，仍然存在争用

---

好问题！我也想听听专家们对此的看法。然而，我担心的是，它可能会以基于意见的方式关闭。是的，我担心同样的结果：D但我希望，由于Azure Service Bus或其他事件总线在幕后的工作方式而采用这种或那种方式的纯技术原因不是那么固执己见。