Это общий вопрос, потому что он применим не только к моему сценарию (с Azure Service Bus), но и к любой шине событий в контексте публикации / подписчиков с событиями.
Вопрос является: Есть ли какие-либо предпочтения в отношении архитектуры / топологии, в которой темы не должны быть разделены между производителями? Другими словами: одна топика c на производителя событий VS одна топика c, общая для нескольких производителей?
У меня есть одно явное предпочтение: одна топи c должна принадлежать и быть доступной только одному производителю, а также другим производителям. Но я, похоже, единственный в команде с таким мнением, в то время как у других, похоже, нет проблем с тем, чтобы делить одни и те же топи c между разными производителями событий «для простоты», и я не могу спорить с точки зрения техническая жизнеспособность ..
Я надеюсь найти ценные ответы и полезные практики, возможно, с более технической точки зрения, потому что мои рассуждения с более деловой / организационной точки зрения, так как я исходят из DDD фона, а остальные нет ..
- topi c - это окно вывода для связи один-ко-многим (которую я интерпретирую как один издатель событий, несколько подписчиков)
- Топи c может иметь дело с различными типами сообщений о событиях, если они каким-то образом связаны (и это очень относительно, конечно)
- В DDD Существует концепция ограниченного контекста, и мне нравится рассматривать микросервисы / модули как способ реализации этих ограниченных контекстов. Поэтому, даже если некоторые другие службы «думают», что они хотят опубликовать sh что-то связанное и хотят получить доступ к общим topi c для публикации sh, я бы сказал, что они принадлежат другому ограниченному контексту, и им следует имеют свои собственные топи c.
- Если несколько производителей действительно принадлежат к одному и тому же ограниченному контексту, то я бы сказал, что только одна служба (или инфра-модуль) должна отвечать за публикацию событий, которые произошли в ограниченном контексте.
- Возможно, что производитель хочет также получать события от других производителей (это также индекс). Не имеет смысла, что производитель подписывается на одну и ту же топику c и должен различать сообщения в зависимости от того, были ли они созданы самим собой или другими.
Как вы можете видеть, из * С точки зрения 1049 * -i sh, несколько производителей, нуждающихся в публикации в одной и той же топике c, могут вызвать запах дизайна. Я не говорю, что это невозможно сделать, я пытаюсь выяснить, следует ли этого избегать ТАКЖЕ с технической точки зрения.
Кто-нибудь имеет практический опыт в этом вопросе?
PS: есть аналогичный вопрос о Кафке , но я не думаю, что он точно такой же, как Кафка использует другой технический подход для издателя-подписчика
ОБНОВЛЕНИЕ 1 : Я не знаю NServiceBus, но я немного поработал с MassTransit, и при использовании создания топологии в MassTransit (который является единственным способом) он создает разные темы не только для производителя, но и для типа сообщения.