Поскольку оба являются сообщениями и оба могут быть доставлены асинхронно, это может показаться серой зоной, но в статье ниже я попытаюсь провести четкое различие между ними.
Команда
Команда представляет собой запрос/намерение, которое хочет исполнить эмитент.
Считайте это общением один на один, когда эмитент знает получателя, например, «Эй, Абхинав! Пожалуйста, ужинайте»..
Это означает, что вызывающая система осведомлена о поведении вызываемой системы. Существует более высокая степень поведенческой связи.
Чтобы объяснить последующие пункты, я возьму пример, представьте себе страховую компанию, в которой есть специальный отдел, предназначенный для общения с клиентами, в отделе есть служба уведомлений. Эта услуга уведомления должна использоваться любым другим отделом, который хочет отправить SMS клиенту.
Соображения из примера —
- Поскольку команда вызывает поведение, которое еще не произошло, она может быть отклонена получателем (допустим, код страны не поддерживается).
- Команду могут вызывать несколько издателей, но есть один получатель (служба уведомлений). Отправляется команда.
- Получатель (служба уведомлений) владеет схемой команды. Получатель управляет информацией, необходимой ему для выполнения действия.
- Существует более высокая степень связи домена, поскольку отправитель команды знает получателя и схему, необходимую для выполнения работы.
События
События, с другой стороны, представляют собой факты на определенный момент времени.Уведомление о чем-то, что уже произошло в прошлом.
Считайте это объявлением: «Привет всем! Ужин подан.
Возьмем другой пример, допустим, в системе создан новый клиент. Потребности отдела маркетинга и отдела андеррайтинга заинтересованы в любом созданном новом клиенте.
Соображения из примера —
- Источник события не имеет информации о том, кто все слушает информацию, это трансляция. Опубликовано событие.
- У события может быть ноль или более получателей.
- Схема события принадлежит источнику события.
- Меньшая степень связанности, поскольку источник события не направляет команды/запросы нижестоящим службам, вместо этого он позволяет нижестоящим службам самим определять, что нужно делать, когда событие произошло. При этом схема события действует как публичный договор. В толстых событиях нижестоящие сервисы начнут увеличивать доступную информацию. А в случае с тонкими событиями сервисы будут запрашивать у источника события дополнительную информацию, которая увеличивает связанность (об этом я рассказывал в другой своей статье).
Заключение
Если мы ожидаем, что наше событие всегда будет обрабатываться конкретным получателем, то я думаю, что мы говорим о команде, реализованной как событие.
Если вы нашли статью полезной или если есть какой-либо другой аспект, который вы хотели бы, чтобы я осветил, сообщите мне об этом в отзыве.