Это одна из тех «ям успеха» в SOA, из-за которых Уди пытается вам очень трудно убежать.
Основная двойственность такова:
- Команды должны отправляться многими клиентами и получаться из одного авторитетного источника.
- События должны публиковаться из одного авторитетного источника и получать многие клиенты.
Но этот единственный авторитетный источник является ЛОГИЧЕСКИМ авторитетным источником. Важным моментом является то, что если меня интересуют все данные IPositionMessage
, должен быть только один логический пункт (queuename @ servername), куда я отправляю свои запросы на подписку.
Это не означает, что несколько физических процессоров в одной и той же логической службе не могут публиковать все события одного и того же типа, если публикуемые ими данные являются авторитетными.
Ключ заключается в том, что все ваши физические процессоры должны совместно использовать одно хранилище подписки. Фактически, вы можете захотеть, чтобы одна физическая конечная точка обрабатывала только запросы на подписку и вообще не обрабатывала. Он просто получает запросы на подписку (QueueX @ ServerY заинтересован в IPositionMessage) и обновляет хранилище подписки.
Затем каждый процессор, связанный с тем же хранилищем подписки, отправляется на публикацию IPositionMessage и обнаруживает, что QueueX @ ServerY заинтересован, и отправляет копию события в это местоположение.
Это будет немного сложно проглотить в среде разработчиков с работающим профилем NServiceBus.Lite, потому что хранилище подписки находится в оперативной памяти по умолчанию, поэтому очевидно, что оно не будет общим и не будет работать правильно, так что будьте готовы к этому.