EDA: "каскадные" события или явные команды?

сценарий

Допустим, у меня есть три основных компонента системы:

  1. UI - собирает входные данные от пользователя и создает команду LoginUserCommand, которая отправляется по шине сообщений. Пользовательский интерфейс затем прослушивает эту шину сообщений для MessageReceivedEvent(s).

  2. Служба пользователя - получает LoginUserCommand и вызывает UserLoggedInEvent. Важнейшей частью здесь является то, что службе сообщений нужно сообщить, чтобы начать получать сообщения.

  3. Служба сообщений - вызывает MessageReceivedEvent(s) для зарегистрированных пользователей.

Опции

У меня вопрос дизайна, касающийся взаимодействия между Сервисом пользователя и Сервисом сообщений.

Когда пользователь входит в систему, необходимо выполнить ряд действий - службы должны координировать свои действия, чтобы пользовательский интерфейс начал получать сообщения.

Нужно ли мне...

  • Служба пользователей вызвала UserLoggedInEvent и служба сообщений прослушивает это событие и выполняет работу, необходимую для получения сообщения пользователем?

...или же...

  • Пользуется ли пользовательская служба вызовом UserLoggedInEvent, НО, затем создает команду StartMessageReceivingCommand и явно отправляет ее службе сообщений?

Вопрос

Каковы плюсы / минусы каждого подхода? (каскадные события против явных команд). Есть ли другие варианты?

Источник

2 ответа

Если ваши сервисы являются реальными сервисами, просто создайте пользовательский логин и позвольте "службе сообщений" решить, что делать дальше. пользовательская служба не должна знать о службе сообщений, которая должна начинать прием сообщений, если пользователь вошел в систему. Просто создайте событие и пусть каждый подписчик сам решает, что делать дальше.

Источник

Это не имеет большого смысла для меня. Сам интерфейс не является логическим сервисом.

Являются ли MessageReceivedEvent сообщений, опубликованных службой сообщений, достаточно публично, чтобы любой пользовательский интерфейс мог подписаться на этот канал? Если нет, то, возможно, эти сообщения вообще не должны публиковаться.

Если пользователю не разрешено обрабатывать MessageReceivedEventЕсли они не вошли в систему, то служба User/Security гарантирует, что этого не произойдет.

Если MessageReceivedEventЕсли вы действительно хотите опубликовать, то почему бы не запустить службу пользователя в процессе пользовательского интерфейса?

  1. Процесспользовательского интерфейса подписывается (отправляет запрос на подписку в службу сообщений) на MessageReceivedEvent
  2. Пользовательский интерфейс отправляет LoginUserCommand переместить конечную точку пользовательского сервиса и локально обрабатывать UserLoggedInReply
  3. Есть два обработчика для MessageReceivedEvent в процессе пользовательского интерфейса
    • первый обработчик принадлежит пользовательской службе и вызывает bus.DoNotContinueDispatchingCurrentMessageToHandlers(), если пользователь не вошел в систему
    • Второй обработчик принадлежит какой-то другой службе, которая на самом деле делает что-то полезное с MessageReceivedEvents

На шаге 3, когда пользователь вошел в систему, первый обработчик не работает. Если пользователь не вошел в систему, первый обработчик останавливает другой MessageReceivedEvent обработчики из runnig вообще.

Там больше об указании порядка сообщений здесь

Надеюсь это поможет

Источник
Другие вопросы по тегам