Сравните смысл события с командой в интеграции микросервисов: как это различие определяет ответственность отправителя и получателя?
Событие сообщает о факте, который уже произошёл: отправитель не указывает конкретному получателю, какое действие выполнить. Команда выражает намерение выполнить действие и адресована владельцу соответствующей ответственности. Поэтому событие обычно допускает нескольких независимых подписчиков, а команда должна иметь понятного исполнителя, который может принять, отклонить или отложить запрос.
В распределённых системах сервисы стремятся развиваться независимо и не раскрывать друг другу внутреннюю реализацию. Интеграция только через прямые вызовы часто превращает отправителя в координатора чужой бизнес-логики.
Разделение событий и команд возникло как способ явно описать семантику сообщения. Получатель должен понимать, ему сообщают результат или предлагают выполнить действие, поскольку от этого зависят маршрутизация, обработка ошибок, владение бизнес-правилом и ожидания по ответу.
Если сообщение с требованием выполнить действие оформить как событие, получатель может не понимать, обязан ли он реагировать, можно ли отказаться и кто отвечает за результат. Несколько подписчиков способны выполнить действие повторно или по-разному, а отправитель начнёт неявно зависеть от поведения конкретных потребителей.
Обратная ошибка тоже опасна: публикация факта как команды искусственно создаёт одного «обязательного» обработчика. Это ограничивает добавление новых потребителей и смешивает произошедшее изменение с распоряжением.
Событие формулируется в прошедшем времени или как зафиксированный факт: «заказ оплачен», «адрес изменён». Его источник отвечает за корректность факта и его контракта, но не за действия всех подписчиков. Каждый потребитель самостоятельно решает, имеет ли этот факт значение для его модели.
Команда формулируется как намерение: «зарезервировать товар», «проверить лимит». Отправитель выбирает адресата или логического владельца операции и передаёт ему запрос. Получатель отвечает за проверку прав, бизнес-правил и итог выполнения; результат может быть представлен ответом, отдельным событием об успехе или отказе.
Выбор определяется не транспортом. Одно и то же сообщение, переданное через брокер, может быть командой или событием: решающими являются смысл, ожидаемая ответственность и правила взаимодействия.
После выполнения команды сервис обычно публикует событие о результате. Например, запрос на резервирование является командой, а «товар зарезервирован» или «резервирование отклонено» — событиями. Это позволяет разделить намерение и подтверждённый факт, не заставляя подписчиков угадывать состояние операции.
Компромисс состоит в том, что команды дают более явное управление и понятную обработку отказа, но сильнее связывают отправителя с владельцем операции. События лучше подходят для расширения числа потребителей и слабой временной связанности, однако требуют ясной семантики факта и не гарантируют, что кто-либо выполнит нужное действие.
Сервис заказа должен инициировать резервирование товара. Команда может отправить прямой запрос складскому сервису: это даёт быстрый и однозначный результат, но создаёт синхронную зависимость. Другой вариант — опубликовать событие «заказ требует резервирования»; он слабее связывает сервисы, но размывает владельца действия и усложняет понимание отказа.
Выбран вариант с явной командой складскому сервису, поскольку именно он владеет остатками и правилами резервирования. После обработки склад публикует событие «резервирование выполнено» или «резервирование отклонено», а сервис заказа меняет состояние заказа на основании этого факта. В результате ответственность за решение остаётся у склада, а новые потребители могут подписываться на результат без превращения события в скрытую команду.
Да. Например, сервис уведомлений получает событие «заказ оплачен» и на его основании создаёт внутреннюю команду «отправить письмо». Это не меняет семантику исходного сообщения: событие сообщает факт, а команда внутри сервиса инициирует конкретное действие.
Важно не выдавать реакцию одного потребителя за обязательную часть контракта события. Источник события не должен предполагать, что конкретный подписчик существует или завершит нужную ему операцию.
Нет. Имя — только сигнал намерения. Контракт должен описывать смысл сообщения, владельца бизнес-операции, допустимые результаты, условия отказа и то, является ли сообщение фактом прошлого или запросом на будущее действие.
Сообщение с названием «ОбновлениеЗаказа» может оказаться неясным: оно сообщает уже выполненное изменение или требует его выполнить. Такая двусмысленность приводит к разным трактовкам у команд и делает интеграцию хрупкой даже при технически совместимой схеме.
Технически одно сообщение можно разослать нескольким получателям, но семантически это опасно, если все они считаются исполнителями одной операции. Тогда неясно, кто принимает окончательное решение, как объединять отказы и кто отвечает за побочные эффекты.
Если нужны независимые реакции нескольких сервисов, обычно отправляют команду одному владельцу, а после результата публикуют событие. Для нескольких самостоятельных действий лучше определить отдельные команды либо использовать событие как общий факт, не выдавая его за распоряжение.