Практика для разработки архитектуры сервиса, которую в последствии можно переложить на event based architecture. Основное проектирование заключается в описание поведения системы на основе событий. События получаются в следствие действий акторов. Акторы выбирают действие на основе доступной информации.
Этапы проведения
- Big picture
- собираем события на единую линию времени
- параллельные события разделяем с помощью swimlane
- проверяем корректностью с помощью чтения вперёд по временной линии и назад
- события, которые делят контексты, делаем БОЛЬШЕ, чтобы понять переход между состояниями
- Process modeling
- докидываем к событиями акторов и команды
- если события из внешней системы, её тоже подписываем
- для принятие решений акторам нужна рид модель
- Software design
- докидываем аггрегаты, чтобы поменять сущности
- emerging bounded context
Чеклист граблей
- Event Storming описывает бизнес-поведение системы, а не техническую реализацию алгоритма команд.
- В названии команд и событий используются бизнес-термины, а не техническое описание алгоритма работы.
- Соблюдается аннотация Event Storming, как в последовательности вызова, так и в наборе стикеров.
- Получение необходимых данных для принятия решения акторами происходит с помощью read model.
- События называются с помощью однозначного глагола в прошедшем времени. В случае бизнес-событий — специфика бизнеса (что произошло в терминах бизнеса), а не в терминах технической реализации алгоритма. В случае со стриминг-событиями — какая операция произведена над ресурсом.