Событийная архитектура часто воспринимается как современный и гибкий способ построения систем. Но действительно ли вы понимаете, как работает ваша система?
Разница между событием и состоянием:
- Событие — факт, что что-то произошло (UserRegistered, PaymentProcessed).
- Состояние — текущий статус системы или объекта (user.status = "active").
Сложность возникает, когда начинаете проектировать систему через события, а не через состояния.
Вы получаете событие UserRegistered. Что дальше? Может ли пользователь сразу делать заказы? Можно ли отправить ему email? А можно ли его заблокировать?
Если Вы не знаете, какие состояния доступны и как они связаны , то Вы не контролируете систему.
События легко превращаются в «спагетти»:
- Одно и то же событие может вызывать разные действия в разных частях системы.
- Бизнес-логика распыляется по обработчикам событий.
Вместо того чтобы создать поведение системы, создаёте «сетевой клубок» реакций.
Когда Вы начинаете с модели состояний:
- Вы понимаете, какие переходы возможны.
- Вы блокируете недопустимые действия.
- Вы можете доказать корректность поведения системы.
- Вы упрощаете тестирование, отладку, мониторинг и документацию.
Неявные состояния возникают когда Вы не думаете в терминах состояний.
События — это инструмент, но он должен быть следствием , а не моделью.
Кто мыслит только событиями — тот не подключает математику автоматов.
События — это импульсы. Состояния — это модель.
