每个事件生产者一个主题 VS 在多个生产者消息传递架构之间共享一个主题

Question

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

问题是：是否更倾向于拥有一个不能在生产者之间共享主题的架构/拓扑？ 换句话说：每个事件生产者一个主题 VS 多个生产者共享一个主题？

我有一个明确的偏好：一个主题应该只由一个制作人拥有和访问，如果其他制作人。但我似乎是团队中唯一一个持这种观点的人，而其他人似乎“为简单起见”在不同事件制作者之间共享同一主题似乎没有任何问题，而且我无法在技术可行性方面真正争论。 .

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

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

如您所见，从 DDD 的角度来看，需要在同一主题中发布的多个生产者会引发设计气味。我并不是说它不能完成，我试图从技术角度找出是否也应该避免它。

任何有这方面实践经验的人？

PS：有一个关于 Kafka 的类似问题，但我认为这与 Kafka 对发布者 - 订阅者使用不同的技术方法完全相同

更新 1：我不知道 NServiceBus，但我已经在 MassTransit 上工作了一些，当利用 MassTransit 的拓扑创建（这是唯一的方法 afaik）时，它不仅为每个生产者而且每个消息类型创建了不同的主题。

Answer 1

再补充几个我认为我们应该尽可能为每个生产者使用一个主题的原因：

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