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