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

Команда

Команда представляет собой запрос/намерение, которое хочет исполнить эмитент.

Считайте это общением один на один, когда эмитент знает получателя, например, «Эй, Абхинав! Пожалуйста, ужинайте»..

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

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

Соображения из примера —

  1. Поскольку команда вызывает поведение, которое еще не произошло, она может быть отклонена получателем (допустим, код страны не поддерживается).
  2. Команду могут вызывать несколько издателей, но есть один получатель (служба уведомлений). Отправляется команда.
  3. Получатель (служба уведомлений) владеет схемой команды. Получатель управляет информацией, необходимой ему для выполнения действия.
  4. Существует более высокая степень связи домена, поскольку отправитель команды знает получателя и схему, необходимую для выполнения работы.

События

События, с другой стороны, представляют собой факты на определенный момент времени.Уведомление о чем-то, что уже произошло в прошлом.

Считайте это объявлением: «Привет всем! Ужин подан.

Возьмем другой пример, допустим, в системе создан новый клиент. Потребности отдела маркетинга и отдела андеррайтинга заинтересованы в любом созданном новом клиенте.

Соображения из примера —

  1. Источник события не имеет информации о том, кто все слушает информацию, это трансляция. Опубликовано событие.
  2. У события может быть ноль или более получателей.
  3. Схема события принадлежит источнику события.
  4. Меньшая степень связанности, поскольку источник события не направляет команды/запросы нижестоящим службам, вместо этого он позволяет нижестоящим службам самим определять, что нужно делать, когда событие произошло. При этом схема события действует как публичный договор. В толстых событиях нижестоящие сервисы начнут увеличивать доступную информацию. А в случае с тонкими событиями сервисы будут запрашивать у источника события дополнительную информацию, которая увеличивает связанность (об этом я рассказывал в другой своей статье).

Заключение

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

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