【发布时间】：2020-06-23 06:22:15
【问题描述】：
这是一个有点笼统的问题，因为它不仅适用于我的场景（使用 Azure 服务总线），而且适用于发布/订阅事件上下文中的任何事件总线。
问题是：是否倾向于拥有一个不能在生产者之间共享主题的架构/拓扑？ 换句话说：每个事件生产者一个主题 VS 多个生产者共享一个主题？
我有一个明确的偏好：一个主题应该由一个生产者拥有和访问，如果其他生产者也应该拥有和访问。但是我似乎是团队中唯一有这种观点的人，而其他人似乎在“为简单起见”在不同的事件制作者之间共享相同的主题方面没有任何问题，我不能真正争论 技术可行性..
我希望从更技术的角度找到有价值的答案和良好实践，因为我的推理是从更多的业务/组织角度来看，因为我来自 DDD 背景，而其他人则没有。
- 主题是一对多通信的输出框（我将其解释为一个事件发布者，多个订阅者）
- 一个主题可以处理不同类型的事件消息，只要它们以某种方式相关（当然这是非常相关的）
- 在 DDD 中，有一个限界上下文的概念，我喜欢将微服务/模块视为实现这些限界上下文的一种方式。因此，即使其他一些服务“认为”他们想要发布相关内容并想要访问要发布的共享主题，我认为它们属于不同的有界上下文并且它们应该有自己的主题。
- 如果多个生产者确实属于同一个限界上下文，那么我认为应该只有一个服务（或基础模块）负责发布限界上下文中发生的事件。
- 生产者可能还想消费来自其他生产者的事件（它也是一个下标）。生产者订阅同一个主题并且必须根据消息是由自己产生还是由其他人产生来区分消息是没有意义的。
如您所见，从 DDD 的角度来看，需要在同一主题中发布的多个生产者会引发设计异味。我并不是说它不能做到，我试图从技术角度找出是否应该避免它。
谁有这方面的实践经验？
PS：有a similar question about Kafka，但我不认为它与Kafka对发布者-订阅者使用不同的技术方法完全相同
更新 1：我不知道 NServiceBus，但我已经使用 MassTransit 进行了一些工作，并且在利用 MassTransit 的拓扑创建（这是 afaik 的唯一方法）时，它不仅为每个生产者创建了不同的主题，而且为每个消息创建了不同的主题输入。
【问题讨论】：
-
好问题！我也很想听听专家对此的看法。但是我担心它可能会以
opinion based的身份关闭。 -
是的，我害怕同样的结果 :D 但我希望纯粹的技术原因可以采用一种或另一种方式，因为 Azure 服务总线或其他事件总线如何在幕后工作没有那么固执己见。
标签： architecture azureservicebus event-bus azure-servicebus-topics message-bus