Пример того, как отобразить выгрузку из внешней системы (и в целом интеграцию) в терминах предметной области.

When an event occurred, the world has changed.

Результат Chaotic Exploration

Результат Timeline Enforcement

А цветное все такое, потому что оранжевых стикеров сильно не хватило 🤷‍♂️😂

Пример начала покера

Если кто-то пропустил, в комментариях еще был пример 12 палочек.

Инсайт участников с одной из крайних сессий Event Storming.

В начале модели кто-то разместил событие «воронка продаж сформирована». Другой участник задал вопрос «как формируется воронка продаж?» и открыл ящик пандоры.

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

Например:
1. Продажи 2 месяца формируют воронку на 10.000 потенциальных клиентов, но в после старта привлечения только 10% проходят проверку на риски, и это 10% от 20% заинтересовавшихся от тех 10.000.
2. Существует специфика процессов под определенную ЦА. Конда доля этой ЦА низкая, – специфика не существенна. Если доля доходит до существенного уровня, - требуется перестройка.
3. Часть клиентов экономически более выгодны для продаж и разумный фокус - продавать там, где больше платят. Но продажи - это не всё и на обслуживании и реализации контракта, затраты и убытки могут превысить выручку, как из-за неготовности процессов, так и исходя из специфики ЦА/контракта.

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

Циклы в Event Storming

В event storming нет циклов и нет control flow. В event storming события.

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

Если модели согласованы и хочется цикл, то на самом деле это уже не цикл, просто тот же самый процесс.

Если хочется показать, что где-то есть цикл, просто напишите рядом комментарий.

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

When using an event-driven architecture, a model that is based on events must replace a model that is based on data. In the event-driven paradigm, the events are more important than the data, which still has value 👌

Стоит ли предоставлять доступ к модели предметной области через внешние API?

Tempting though it may be, it is not advisable to directly expose a domain model via RESTful HTTP.

This approach often leads to system interfaces that are more brittle than they need to be, as each change in the domain model is directly reflected in the system interface. There are two alternative approaches for combining DDD and RESTful HTTP.
…
The first approach is to create a separate Bounded Context for the system’s interface layer (..). This can be deemed a classic approach, as it views the system’s interface as a cohesive whole that is simply exposed using resource abstractions instead of services or remote interfaces.
…
Another approach is appropriate when more emphasis is placed on standard media types. (...) a domain model can be created to represent each standard media type. Such a domain model might even be reused across clients and servers, although some REST and SOA proponents view this as an anti-pattern.

Note: Such an approach is essentially a Shared Kernel (3) or Published Language (3) in DDD terms.

(c) Vaughn Vernon, Implementing Domain-Driven Design

А имеет вообще смысл написать на русском небольшую книгу-инструкцию по Event Storming? Или поезд уже давно ушел)))

Остались вообще те, кто книгами интересуется?)))

А то материала масса)

Event Storming Street Art

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

У кого в этом месяце три очных сессии Big Picture Event Storming по два дня, тот я :)

Рад, что очный формат все активнее возвращается в жизнь.

UPD: чуть позже расскажу, почему этому рад :)

Все больше обсуждений идет вокруг «AI заменит то, AI заменит это». Однако я уверен, что исследовательские техники с вовлечением большого числа людей, вроде Big Picture Event Storming не заменить AI.

И вот почему:
- Event Storming вскрывает много информации, которой просто нигде не зафиксировано, кроме как в головах конкретных людей, - это следствие того, что есть регламенты, а есть то, как они исполняются и в этом часто высокий уровень вариативности и, если будет угодно, креативности, причем различной у различных людей
- В AI практически невозможно загрузить весь требуемый контекст, - он и не формализуем в общем случае и непонятно, какие именно аспекты контекста загружать, пока они не всплывут в рамках исследования
- Модель должна быть сфокусированной на некотором аспекте, без совместного диалога сводимости в однозначном понимании модели не произойдет

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

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

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

Посмотрев на такую модель можно отследить и паттерны, – больше формальных коммуникаций или случайных, о каких случаях как узнают люди (опять же – случайно или нет, своевременно или нет).

Вспоминая характеристики качественной информации по Веструму:
– Информация должна предоставлять ответы на заданные вопросы
– Быть своевременной и
– Должна быть представлена в таком виде, в котором она может быть эффективно использована получателем

Можно оценить, насколько циркуляция информации в компании/департаменте/команде удовлетворяет этим характеристикам и запланировать улучшения.

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

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

Системные паттерны, которые можно увидеть в построенной модели.

Трагедия общин
Обычно проявляется как высокая плотность стикеров в центре модели и простота на краях. Конкретный пример может звучать как «вместо решения проблемы в домене (например, проверка товара при размещении) все проблемы сваливаются в общий процесс согласования».

Механизм возникновения (развития паттерна) примерно такой:
Продажи: у нас проблема с ценами -> проверят на согласовании
Склад: у нас проблема с остатками -> проверят на согласовании
Финансы: у нас проблема с лимитами -> проверят на согласовании

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

Компенсирующие обратные связи
Добавление защитных/компенсационных механизмов дестимулирует качество на входе. Деминг это называл «контроль качества на выходе не создает качество внутри».
В модели проявляется в виде ассиметрии сложности – простые входные процессы, сложные выходные. Суть в том, что чем больше проверок справа (проверка, отгрузка), тем менее аккуратно работают слева (создание, подготовка).

Механизм возникновения может быть таким:
Добавили проверку качества заказов на складе
Менеджеры стали менее аккуратно заполнять заказы ("все равно ж проверят")
Проблем на складе стало больше -> добавили еще проверок
Качество входящих заказов упало еще больше

Результат, – чем больше контроля, тем хуже работают контролируемые процессы.