Полиморфная маршрутизация в Azure Service Bus Transport версии 6 NServiceBus: как обойтись без перечисления всех конкрет ⇐ C#

[Anonymous]

Мы пытаемся перейти с NServiceBus 8 на NServiceBus 10, и вместе с этим появляется новая топология для транспорта Azure Service Bus. Мы столкнулись с некоторыми проблемами при переходе от топологии с одной темой к топологии "тема-за-событие".
Наша настройка примерно следующая. У нас есть базовый класс событий для заказа товара:

Код: Выделить всё

public class ProductOrdered : IEvent {
public int OrderId { get; set; }
}

Для различных групп продуктов в нашем портфолио мы создаем этот тип, чтобы включить более конкретные свойства.
Тогда у нас есть два типа подписчиков:

• Подписчики, которые просто заинтересованы в событии SomeConcreteProductOrdered и, таким образом, реализуют IHandleMessages.
• Подписчики которым не нужно знать всю специфику различных групп продуктов, а просто интересоваться любым ProductOrdered. Они будут реализовывать IHandleMessages
  .

Согласно документации, способ поддержки такого рода полиморфизма состоит в том, чтобы указать подписчику, какие очереди следует прослушивать:

Код: Выделить всё

topology.SubscribeTo
("SomeConcreteProductOrdered");
topology.SubscribeTo("AnotherConcreteProductOrdered");

Однако для этого нам потребуется полностью перечислить различные реализации ProductOrdered. Что-то, что может измениться со временем и потребует поддержки в нескольких местах, но, прежде всего, то, о чем до сих пор эти подписчики не имели права знать.
Итак, нам остается задаться вопросом, есть ли другой способ настроить это так, чтобы нам не приходилось перечислять все конкретные реализации этого базового класса в потребляющих конечных точках?
Мы думали о том, чтобы конечные точки публикации публиковали сообщение как на Тема SomeConcreteProductOrdered и тема ProductOrdered, чтобы разные потребители могли просто прослушивать темы в соответствии со своими реализациями IHandleMessages.
Альтернативой могло бы быть создание подписки из темы SomeConcreteProductOrdered на тему ProductOrdered (по сути, перестроение дерева наследования в темах и подписках), но нам было интересно, стоит ли можно использовать установщики конечных точек для автоматического предоставления этих ресурсов.

Подробнее здесь: https://stackoverflow.com/questions/798 ... sion-6-how