Шаблоны распределенного обмена сообщениями: почему команда может иметь только одного слушателя?

Question

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

Мне интересно, почему и действительно ли это так.

Если мне нужно уведомить кого-либо разными способами (по электронной почте, по факсу, посредством push-уведомления), что не так, публикуя команду SendNotification и позволяя трем различным подписчикам получать команду и обрабатывать уведомление? Каждый знает, как уведомить пользователей по почте; вторая умеет уведомлять пользователей по факсу; третий знает, как уведомить пользователей облаком сообщений Google.

Answer 1

Мне интересно, почему и действительно ли это так.

В контексте обмена сообщениями я не думаю, что это действительно так. Обмен сообщениями - это дизайн «многие ко многим». В то время как семантика команды может повысить вероятность того, что только один компонент обрабатывает командное сообщение, применение отношения один к одному лишает вас части преимуществ обмена сообщениями.

Answer 2

Обычно должен быть один центральный орган, который решает, уместно ли принять запрос на уведомление, и затем он может использовать механизмы , с помощью которых это может произойти через другиесредства (включая специальные команды, предназначенные для соответствующего поставщика).

Кто / Какой компонент отвечает за обнаружение "электронной почты, решив, что это не работа для нее, факс решил, что это не работа дляэто, толчок решил, что это не работа для него "?Если каждый компонент решает сам, трудно обнаружить, что уведомление не было отправлено.

По сути, вы отправляете команды своим источникам истины .Надеюсь, у вас есть только один из них для каждого домена.