Средний

События против команд

Урок 1 из 3 в курсе Событийная архитектура

Содержание курса (1/3)
1 События против команд
2 Event Sourcing и CQRS 3 Kafka и event streaming

События против команд

командa говорит 'сделай', событие сообщает 'случилось' — разница принципиальная.

Почему это важно: Путаница между событиями и командами приводит к тесной связности сервисов и распределённому монолиту.

Главная идея

Команда — императив, у неё один получатель и она может быть отклонена. Событие — факт, у него много подписчиков и оно неизменно.

Как это выглядит на практике

  1. Команда: 'Создай заказ' (CreateOrderCommand) — обрабатывается одним сервисом.
  2. Событие: 'Заказ создан' (OrderCreated) — публикуется и подхватывается всеми заинтересованными.
  3. Сервисы биллинга, склада, аналитики реагируют на событие независимо.
  4. Публикатор не знает о подписчиках — слабая связность.

Что происходит под капотом

  • Команды направляются конкретному обработчику; события публикуются в шину.
  • События — в прошедшем времени (OrderCreated, не CreateOrder).
  • Шины событий: Kafka, RabbitMQ, NATS, AWS SNS/EventBridge.
  • Подписчики добавляются и удаляются без изменения публикатора.

Типичные ошибки и заблуждения

  • Ошибка: события и команды взаимозаменяемы. Они решают разные задачи.
  • Ошибка: события всегда лучше команд. Иногда нужна именно команда (атомарный запрос).
  • Ошибка: шина событий = magic glue. Она требует мониторинга и понимания гарантий.
  • Ошибка: события заменяют API. Часто они дополняют, а не заменяют.

Ключевые выводы

  • Команда = императив, событие = факт.
  • События в прошедшем времени, неизменны.
  • Подписчики не влияют на публикатора.
  • Слабая связность — главная ценность событийной модели.

Термины урока

Command: запрос на выполнение действия.
Event: факт о произошедшем изменении состояния.
Event bus: инфраструктура для публикации/подписки на события.
Loose coupling: слабая связность между компонентами.

Связь с работой backend-разработчика

Понимание разницы между командами и событиями — фундамент проектирования распределённых систем.

Мини-разбор реальной ситуации

Команда отправляла 'события' с императивами вроде 'OrderShouldBeShipped'. Они превратились в скрытые команды, и появилась невидимая связность между сервисами.

Что запомнить

  • События — в прошедшем времени.
  • Команда — императив с одним получателем.
  • Слабая связность — цель.

Итог

Чёткое разделение команд и событий — основа здоровой событийной архитектуры.

Комментарии к уроку

Войдите, чтобы оставить комментарий.

Пока нет комментариев — будьте первым.