Понимаем события в микросервисной архитектуре
Когда проектируешь микросервисы, быстро сталкиваешься с понятием "событие". Но не все события одинаковы. Есть два ключевых типа: доменные события и интеграционные события. И если их не различать, легко запутаться и выстроить неустойчивую систему.
Разберёмся, чем они отличаются, и как правильно использовать каждый тип на практике.
Что такое доменное событие
Доменное событие — это отражение изменений внутри бизнес-логики одного микросервиса. Оно говорит: "У меня что-то важное произошло". Например, в сервисе заказов произошло событие `OrderPlaced`, когда клиент оформил заказ.
Признаки доменного события:
- Оно связано с бизнес-сущностями (например, заказ, пользователь, платеж).
- Генерируется внутри одного микросервиса.
- Не предполагает немедленной реакции со стороны других сервисов.
- Используется для поддержки внутренней консистентности (например, триггер транзакции или аудит).
Пример из практики:
Микросервис "Заказы" после сохранения нового заказа публикует событие `OrderCreated`. Это событие может быть использовано внутри самого сервиса, чтобы, например, записать лог или обновить статистику.
Что такое интеграционное событие
Интеграционное событие — это способ сообщить другим микросервисам: "У меня что-то изменилось, возможно, вам стоит отреагировать". Это уже межсервисное взаимодействие.
Характерные черты интеграционного события:
- Отправляется за пределы микросервиса.
- Используется для синхронизации состояния между сервисами.
- Часто публикуется в брокер сообщений (Kafka, RabbitMQ и т.д.).
- Содержит минимум необходимой информации (обычно ID сущности и тип события).
Пример из практики:
После оформления заказа, "Заказы" публикуют интеграционное событие `OrderConfirmed`. Сервис "Склад" слушает такие события, чтобы зарезервировать товар. Это обеспечивает слабую связанность компонентов.
Главное отличие: контекст и аудитория
На практике всё упирается в вопрос: кто должен знать об этом событии и зачем?
- Доменное событие нужно самому сервису — для внутренней логики.
- Интеграционное событие нужно другим сервисам — для координации бизнес-процессов.
Советы по использованию в продакшене
Вот несколько практических рекомендаций, которые помогут избежать проблем:
- Не смешивай контексты. Не стоит использовать одно событие и как доменное, и как интеграционное. Разделяй их явно.
- Упрощай интеграционные события. Не передавай лишние детали. Только то, что действительно нужно потребителю.
- Не завязывайся на порядок. Интеграционные события должны быть идемпотентными — потребители должны уметь обрабатывать их повторно.
Как проектировать события правильно
Чтобы архитектура оставалась гибкой и масштабируемой, подходите к проектированию событий осознанно.
Рекомендации:
- Определи границы контекста каждого микросервиса (bounded context).
- Доменные события оформляй как часть бизнес-модели. Они могут быть полезны даже без публикации.
- Интеграционные события делай максимально простыми и независимыми от внутренней структуры сервисов.
Пример подхода:
В сервисе "Платежи" событие `PaymentSucceeded` может быть доменным. Но если нужно уведомить "Службу доставки", публикуется интеграционное событие `PaymentReceived` с ID заказа и суммой. Это два разных события, обслуживающих разные цели.
Вывод: думай о потребителе события
Разделение на доменные и интеграционные события — не просто теоретическая классификация. Это основа устойчивой микросервисной архитектуры. Когда ты чётко понимаешь, кто потребитель события и зачем оно нужно, становится проще избегать лишней связанности и хаоса.
Правильно оформленные события — это не только про архитектуру. Это про читаемый, поддерживаемый и масштабируемый код. А это уже — профессионализм.
