Event storming

Event storming (ивент сторминг) — это увлекательный и простой для организации практикум по моделированию, который объединяет основные аспекты предметно-ориентированного проектирования, о которых мы говорили в предыдущих главах.

Целью этого практикума является определение фреймворка для исследования предметных областей, накопление знаний и заложение основ единого языка.

Идеально, если в практикуме участвуют разноплановые специалисты. Принимать участие могут все, кто связан с предметной областью: инженеры, эксперты предметной области, владельцы продуктов, тестировщики, дизайнеры пользовательского интерфейса, сотрудники службы поддержки и т. д. Чем больше людей с разным бэкграундом будет вовлечено, тем больше знаний будет получено.

Однако нужно следить за тем, чтобы группа не была слишком многочисленной. Каждый участник должен иметь возможность внести свой вклад в процесс, но это может быть сложно для групп из более чем 10 участников.

Event storming считается низкотехнологичным практикумом, так как он проводится с использованием ручки и бумаги (большого количества бумаги). Давайте посмотрим, что вам понадобится для проведения такой сессии.

Доска тоже сгодится, но она должна быть большой настолько, насколько это возможно — вам потребуется всё доступное пространство для моделирования.

Затем вам понадобится много стикеров разных цветов. Они будут использоваться для представления разных концепций предметных областей и каждый участник должен иметь возможность добавлять их сколько угодно, так что убедитесь, что у вас есть достаточно бумаги разных цветов.

Цвета, которые традиционно используются для моделирования событий, описаны в следующем разделе. По возможности придерживайтесь этих правил.

Вам также понадобятся маркеры, которыми удобно писать на стикерах. Канцелярские товары не должны становиться узким местом для обмена знаниями — маркеров должно быть достаточно для всех участников.

Обычная сессия моделирования длится 2-4 часа, поэтому принесите с собой здоровый перекус для поддержания энергии.

Наконец, вам нужна просторная комната. Убедитесь, что посередине нет огромного стола, который будет мешать участникам свободно перемещаться и наблюдать за пространством моделирования.

Стулья — это большой минус для практикума. Вы хотите, чтобы люди участвовали и делились знаниями, а не сидели в углу и отключались. Поэтому, по возможности, уберите стулья из комнаты.

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

Практикум начинается с мозгового штурма о событиях, связанных с исследуемой предметной областью. Событие предметной области — это что-то интересное, что уже происходило в бизнесе. Важно формулировать события предметной области в прошедшем времени (см. рисунок 8-2) — они описывают то, что уже случилось.

Во время этого этапа все участники берут оранжевые стикеры, записывают все события предметной области, которые приходят в голову, и приклеивают их к полю моделирования.
На этом раннем этапе нет необходимости беспокоиться о порядке событий или даже об избыточности. Этот этап предназначен для генерации возможных событий, которые могут произойти в предметной области.

Группа должна продолжать генерировать события предметной области, пока скорость добавления новых событий окончательно не замедлится.

Затем участники переходят к сгенерированным событиям предметной области и пытаются расставить их в хронологическом порядке, в котором эти события происходят в бизнес-области.

Упорядочивание событий следует начать с «успешного сценария» — потока, описывающего успешный ход событий.

Как только «успешный путь» составлен, можно добавить альтернативные сценарии — например, сценарии, где возникают ошибки или принимаются другие бизнес-решения. Разветвление сценария можно изобразить как два потока, исходящих из предыдущего события или стрелками, нарисованными на поле моделирования, как показано на рисунке 8-3.

Также на этом этапе можно исправить ошибки, убрать дубликаты и конечно же, добавить недостающие события, если таковые обнаружены.

В то время как событие предметной области описывает то, что уже произошло, команды описывают то, что вызвало событие или поток событий. Команды описывают операции системы и, в отличие от событий предметной области, формулируются в повелительном наклонении. Например:

• Опубликовать кампанию
• Откатить транзакцию
• Отправить заказ

Команды записывают на голубых стикерах и размещают на доске перед событиями, которые могут быть произведены ими. Если конкретная команда выполняется актором в определённой роли, информация о нем добавляется к команде на маленьком жёлтом стикере, как показано на рисунке 8-4.

Почти всегда бывают команды, которые добавляются в модель, но не имеют конкретного связанного с ними актора. Во время этого этапа вы определяете автоматизированные правила, которые могут выполнять эти команды.

Автоматизированное правило — это сценарий, в котором выполнение команды запускается событием. Другими словами, команда автоматически выполняется, когда происходит определенное событие предметной области.

На поле моделирования правила представлены фиолетовыми стикерами, соединяющими события с командами, как показано на рисунке 8-5.

Если события и команды далеко друг от друга, на поверхности моделирования можно нарисовать стрелку, соединяющую их.

Пятый этап — дополнение модели внешними системами. Внешняя система определяется как любая система, не входящая в состав исследуемой предметной области. Она может выполнять команды (ввод) или уведомлять о событиях (вывод).

Внешние системы представлены розовыми стикерами (рисунок 8-6).

К концу этого шага все команды должны либо выполняться участниками, либо вызываться внешними системами, либо должны запускаться правила.

Как только все события и команды представлены, участники могут начать думать об организации связанных концепций в агрегаты. Агрегат получает команды и производит события.

Агрегаты представлены в виде больших жёлтых стикеров, команды располагаются слева, а события справа (рисунок 8-7).

Последний этап практикума — выявление агрегатов, связанных друг с другом, по причине тесно связанного функционала, либо по причине связи через правила. Группы агрегатов образуют возможные ограниченные контексты, как показано на рисунке 8-8.

В конце практикума у вас будет модель, описывающая события, команды, агрегаты и даже возможные границы ограниченных контекстов предметной области. Однако все это всего лишь приятные бонусы. Реальная ценность сессии моделирования событий в самом процессе — в обмене знаниями между разными заинтересованными сторонами, синхронизации их ментальных моделей, обнаружении конфликтующих моделей и формулировании единого языка.