这是一个普遍的问题，因为它不仅适用于我的场景（使用 Azure 服务总线），而且适用于发布/订阅者上下文中的任何事件总线。
问题是：有没有偏好在生产者之间不能共享主题的架构/拓扑？ 换句话说：每个事件生产者一个主题 VS 多个生产者共享一个主题？
我有一个明确的偏好：一个主题应该由一个生产者拥有和访问，如果是其他生产者。但我似乎是团队中唯一持此观点的人，而其他人似乎在“为简单起见”在不同的事件制作者之间共享同一主题时没有任何问题，而且我不能真正争论技术可行性。 .
我希望从更技术的角度找到有价值的答案和良好实践，因为我的推理是从更多的业务/组织的角度来看，因为我来自 DDD 背景，而其他人则没有。
- 主题是一对多通信的输出框（我将其解释为一个事件发布者，多个订阅者）
- 一个主题可以处理不同类型的事件消息，只要它们以某种方式相关（当然这是非常相关的）
- 在 DDD 中，有一个限界上下文的概念，我喜欢将微服务/模块视为实现这些限界上下文的一种方式。因此，即使其他一些服务“认为”他们想要发布相关内容并想要访问要发布的共享主题，我认为它们属于不同的有界上下文，并且应该有自己的主题。
- 如果多个生产者真的属于同一个限界上下文，那么我认为只有一个服务（或基础模块）应该负责发布在限界上下文中发生的事件。
- 生产者可能还想消费来自其他生产者的事件（它也是一个下标）。生产者订阅同一个主题并且必须根据消息是由自己产生还是由其他人产生来区分消息是没有意义的。
如您所见，从 DDD 的角度来看，需要在同一主题中发布的多个生产者会引发设计气味。我并不是说它不能完成，我试图从技术角度找出是否应该避免它。
有这方面的实践经验的人吗？
PS：关于 Kafka 有一个类似的问题，但我认为这与 Kafka 对发布者-订阅者使用不同的技术方法并不完全相同
更新 1：我不知道 NServiceBus，但我已经使用 MassTransit 进行了一些工作，并且当利用 MassTransit 的拓扑创建（这是 afaik 的唯一方法）时，它不仅为每个生产者创建了不同的主题，而且为每个消息类型创建了不同的主题。