每个事件生产者一个主题 VS 多个生产者消息架构共享一个主题
One topic per event producer VS One topic shared across multiple producers messaging architecture
这是一个有点笼统的问题，因为它不仅适用于我的场景（使用 Azure 服务总线），而且适用于 publish/subscribers 上下文中的任何事件总线和事件。
问题是：是否有任何偏好 architecture/topology 生产者之间不得共享主题？
换句话说：每个事件生产者一个主题 VS 多个生产者共享一个主题？
我有一个明确的偏好：一个主题应该只由一个制作人拥有和访问，如果其他制作人也应该拥有和访问。但我似乎是一个团队中唯一有这种观点的人，而其他人在不同的活动制作人之间分享相同的话题似乎没有任何问题"for simplicity"，我真的不能争论 技术可行性..
我希望能从更技术性的角度找到有价值的答案和良好实践，因为我的推理是从更 business/organization 的角度出发的，因为我有 DDD 背景，而其他人没有't..
- 主题是一对多通信的输出框（我理解为一个事件发布者，多个订阅者）
- 一个主题可以处理不同类型的事件消息，只要它们以某种方式相关（当然，这是非常相关的）
- 在 DDD 中，有一个边界上下文的概念，我喜欢将 microservices/modules 视为实现这些边界上下文的一种方式。因此，即使一些其他服务 "think" 他们想要发布相关内容并想要访问共享主题以发布，我认为他们属于不同的限界上下文并且他们应该有自己的主题。
- 如果多个生产者确实属于同一个限界上下文，那么我认为应该只有一个服务（或基础模块）负责发布限界上下文中发生的事件。
- 生产者可能还想消费来自其他生产者的事件（它也是订阅者）。生产者订阅相同的主题并且必须根据消息是由自己还是其他人生产来区分消息是没有意义的。
如您所见，从 DDD-ish 的角度来看，需要在同一主题中发布的多个生产者会引发设计气味。我并不是说它不能完成，我试图从技术角度找出是否也应该避免它。
有人对此有一些实践经验吗？
PS：有但我不认为它完全一样，因为Kafka对发布者-订阅者使用不同的技术方法
更新 1：我不知道 NServiceBus，但我在 MassTransit 上工作过一些，当利用拓扑创建到 MassTransit 时（这是 afaik 的唯一方式），它不仅为每个生产者创建不同的主题，而且每个消息类型。
再补充几个我认为我们应该尽可能多地为每个制作人使用一个主题的原因：
- 如果多个生产者将同一个事件发布到同一个主题，则没有明确的事件归属和权限。这与您关于限界上下文的观点相似。
- 当多个生产者发布同一个事件时，它会在这些生产者之间创建一个事件模式耦合。现在，如果不立即影响所有生产者，就无法发展事件模式。这些生产者可以使用事件模式版本控制，但是当多个生产者更新相同的事件模式（并产生不同版本的事件模式）时仍然存在争用
这是一个有点笼统的问题，因为它不仅适用于我的场景（使用 Azure 服务总线），而且适用于 publish/subscribers 上下文中的任何事件总线和事件。
问题是：是否有任何偏好 architecture/topology 生产者之间不得共享主题？ 换句话说：每个事件生产者一个主题 VS 多个生产者共享一个主题？
我有一个明确的偏好：一个主题应该只由一个制作人拥有和访问，如果其他制作人也应该拥有和访问。但我似乎是一个团队中唯一有这种观点的人，而其他人在不同的活动制作人之间分享相同的话题似乎没有任何问题"for simplicity"，我真的不能争论 技术可行性..
我希望能从更技术性的角度找到有价值的答案和良好实践，因为我的推理是从更 business/organization 的角度出发的，因为我有 DDD 背景，而其他人没有't..
- 主题是一对多通信的输出框（我理解为一个事件发布者，多个订阅者）
- 一个主题可以处理不同类型的事件消息，只要它们以某种方式相关（当然，这是非常相关的）
- 在 DDD 中，有一个边界上下文的概念，我喜欢将 microservices/modules 视为实现这些边界上下文的一种方式。因此，即使一些其他服务 "think" 他们想要发布相关内容并想要访问共享主题以发布，我认为他们属于不同的限界上下文并且他们应该有自己的主题。
- 如果多个生产者确实属于同一个限界上下文，那么我认为应该只有一个服务（或基础模块）负责发布限界上下文中发生的事件。
- 生产者可能还想消费来自其他生产者的事件（它也是订阅者）。生产者订阅相同的主题并且必须根据消息是由自己还是其他人生产来区分消息是没有意义的。
如您所见，从 DDD-ish 的角度来看，需要在同一主题中发布的多个生产者会引发设计气味。我并不是说它不能完成，我试图从技术角度找出是否也应该避免它。
有人对此有一些实践经验吗？
PS：有
更新 1：我不知道 NServiceBus，但我在 MassTransit 上工作过一些，当利用拓扑创建到 MassTransit 时（这是 afaik 的唯一方式），它不仅为每个生产者创建不同的主题，而且每个消息类型。
再补充几个我认为我们应该尽可能多地为每个制作人使用一个主题的原因：
- 如果多个生产者将同一个事件发布到同一个主题，则没有明确的事件归属和权限。这与您关于限界上下文的观点相似。
- 当多个生产者发布同一个事件时，它会在这些生产者之间创建一个事件模式耦合。现在，如果不立即影响所有生产者，就无法发展事件模式。这些生产者可以使用事件模式版本控制，但是当多个生产者更新相同的事件模式（并产生不同版本的事件模式）时仍然存在争用