Event Storming – это увлекательный способ собрать вместе разработчиков и экспертов в бизнесе для быстрого, совместного исследования сложной предметной области бизнеса и позволяющий получить на выходе высококачественные модели.
Часы вместо дней и недель.
С чего начать, чтобы начать event storming?
«Давайте соберемся все вместе и разместим в хронологическом порядке все самые важные события из рассматриваемой предметной области и проговорилось и расскажем друг другу, что скрывается за каждым из них… 🧐»
Alberto Brandolini - 50,000 Orange Stickies Later
https://www.youtube.com/watch?v=1i6QYvYhlYQ
https://www.eventstorming.com/#resources
Event Storming на практических кейсах:
http://agilemindset.ru/event-storming-на-практических-кейсах/
Проектирование микросервисов с помощью Event Storming
https://www.youtube.com/watch?v=cG9DVbcPc9M
Митап для SpbDotNet
http://agilemindset.ru/event-storming-избавляемся-от-предположений/
Немного о том, как проходил курс по Event Storming
http://agilemindset.ru/обучение-event-storming-онлайн-как-это-было/
Часы вместо дней и недель.
С чего начать, чтобы начать event storming?
«Давайте соберемся все вместе и разместим в хронологическом порядке все самые важные события из рассматриваемой предметной области и проговорилось и расскажем друг другу, что скрывается за каждым из них… 🧐»
Alberto Brandolini - 50,000 Orange Stickies Later
https://www.youtube.com/watch?v=1i6QYvYhlYQ
https://www.eventstorming.com/#resources
Event Storming на практических кейсах:
http://agilemindset.ru/event-storming-на-практических-кейсах/
Проектирование микросервисов с помощью Event Storming
https://www.youtube.com/watch?v=cG9DVbcPc9M
Митап для SpbDotNet
http://agilemindset.ru/event-storming-избавляемся-от-предположений/
Немного о том, как проходил курс по Event Storming
http://agilemindset.ru/обучение-event-storming-онлайн-как-это-было/
Event Storming pinned «Event Storming – это увлекательный способ собрать вместе разработчиков и экспертов в бизнесе для быстрого, совместного исследования сложной предметной области бизнеса и позволяющий получить на выходе высококачественные модели. Часы вместо дней и недель. …»
❓В чем состоит качество моделей, высокий уровень которого характерен для результатов Event Storming?
🔸Получаемая модель, как правило, не содержит несущественных деталей;
🔸Cессия строится таким образом, чтобы выявить максимальный объем скрытой сложности и неоднозначности;
🔸В Event Storming заложены методы формализации и уточнения определений, которые в итоге становятся Ubiquitous Language, что повышает точность модели
🔸У Event Storming очень простая нотация. Это означает, что полученную модель без труда используют люди с разным опытом (юристы, программисты, логисты, POs), что упрощает проработку, повышая точность и сводит к минимуму ошибки, связанные с неверной трактовкой модели
🔸 Модель имеет фрактальную природу, что облегчает работу с ней: модель – это повторяющиеся структурные цепочки, из которых проявляется сложная структура (привет, complex systems theory)
🔸В Event Storming заложены способы инкрементального расширения нотации. Можно обогатить Bounded Context'ами, Person'ами, критериями приемки, моделями чтения. Это позволяет в том числе провалидировать изначальные предположения.
Можно сказать, что модель, полученная через Event Storming может быть основой для формирования и других моделей или установления первоначального общего контекста перед построением других моделей.
🔸Получаемая модель, как правило, не содержит несущественных деталей;
🔸Cессия строится таким образом, чтобы выявить максимальный объем скрытой сложности и неоднозначности;
🔸В Event Storming заложены методы формализации и уточнения определений, которые в итоге становятся Ubiquitous Language, что повышает точность модели
🔸У Event Storming очень простая нотация. Это означает, что полученную модель без труда используют люди с разным опытом (юристы, программисты, логисты, POs), что упрощает проработку, повышая точность и сводит к минимуму ошибки, связанные с неверной трактовкой модели
🔸 Модель имеет фрактальную природу, что облегчает работу с ней: модель – это повторяющиеся структурные цепочки, из которых проявляется сложная структура (привет, complex systems theory)
🔸В Event Storming заложены способы инкрементального расширения нотации. Можно обогатить Bounded Context'ами, Person'ами, критериями приемки, моделями чтения. Это позволяет в том числе провалидировать изначальные предположения.
Можно сказать, что модель, полученная через Event Storming может быть основой для формирования и других моделей или установления первоначального общего контекста перед построением других моделей.
Периодически буду делиться антипаттернами использования Event Storming. Для этого еще не придумал название, можно покреативить в комментариях.
Наблюдаемое поведение: архитекторным комитетом архитектору выставляется требование готовить архитектурные артефакты в нотации Event Storming.
Конечно, нотацию можно использовать как угодно, но Event Storming – это фасилитационная техника. Составление схемы одним человеком – это не Event Storming. Цель – не картинку нарисовать. Целью может быть «выявить бизнес-требования в понятной для всех нотации и спроектировать реализацию для решения комплексной задачи». Event Storming для такой цели может стать одним из инструментов, например, позволяющий собрать разрозненные знания о предметной области воедино, вместе, так, чтобы у каждого участника был не единичный пазл, а цельная картинка, сложенная из пазлов участников сессии.
С этой 👆высококачественной моделью уже можно работать достаточно эффективно.
Наблюдаемое поведение: архитекторным комитетом архитектору выставляется требование готовить архитектурные артефакты в нотации Event Storming.
Конечно, нотацию можно использовать как угодно, но Event Storming – это фасилитационная техника. Составление схемы одним человеком – это не Event Storming. Цель – не картинку нарисовать. Целью может быть «выявить бизнес-требования в понятной для всех нотации и спроектировать реализацию для решения комплексной задачи». Event Storming для такой цели может стать одним из инструментов, например, позволяющий собрать разрозненные знания о предметной области воедино, вместе, так, чтобы у каждого участника был не единичный пазл, а цельная картинка, сложенная из пазлов участников сессии.
С этой 👆высококачественной моделью уже можно работать достаточно эффективно.
Следующий антипаттерн – «Технические события».
Это то, что может сделать хуже. События должны иметь смысл для экспертов в предметной области. Технические события – это предметная область конкретного варианта технической реализации. Даже если вы разрабатываете нечто сугубо-техническое, вроде SAST, у вас все равно будут события предметной области, только звучать они могут как технические события в случае работы с другим доменом. В банке или ритейле события предметной области легче отделить от сугубо технических, это правда.
Почему это так важно? Потому что язык предметной области универсален, понятен экспертам в предметной области и позволяет:
1. Использовать «События», имеющие бизнес-смысл, в том числе для интеграции систем (и вот уже нет необходимости переводить с бизнес-языка на технический), примеры: «Валютный документ подписан клиентом», «Направлен запрос на брокерское обслуживание», «Партнеру отправлено вознаграждение за кредитный договор»
2. Использовать «Команды», с одной стороны как как элементы бэклога, с другой – API («Назначить встречу», «Перенести встречу», «Подать документ “Предоставление СПД”», «Аннулировать документ»). Появляется соответствие между событиями в бизнесе, командами (действиями), приводящими к этим событиям и бэклогом в единой терминологии в рамках отдельно взятого контекста/домена (так как все-таки контекст является границей существования модели предметной области и терминологии).
Доменный язык дает возможность выбора вариантов реализации. Команда «Подписать ПКБО на обслуживание» при проработке деталей реализации может быть раскрыта как набор элементов бэклога: подписать через ЭЦП, подписать рукой, подписать биометрией, через SMS, кровью.
Отлично же, если у разработки не встают дыбом волосы от фразы «Начислить комиссию за несоблюдение условий бесплатного обслуживания», а тут же находится нужный сервис/API/модуль/… и изменяется его логика, которая так же описана на понятном доменному эксперту языке (в идеале - свой DSL, но это очень дорогое удовольствие и в дикой природе зверь редкий)
Это то, что может сделать хуже. События должны иметь смысл для экспертов в предметной области. Технические события – это предметная область конкретного варианта технической реализации. Даже если вы разрабатываете нечто сугубо-техническое, вроде SAST, у вас все равно будут события предметной области, только звучать они могут как технические события в случае работы с другим доменом. В банке или ритейле события предметной области легче отделить от сугубо технических, это правда.
Почему это так важно? Потому что язык предметной области универсален, понятен экспертам в предметной области и позволяет:
1. Использовать «События», имеющие бизнес-смысл, в том числе для интеграции систем (и вот уже нет необходимости переводить с бизнес-языка на технический), примеры: «Валютный документ подписан клиентом», «Направлен запрос на брокерское обслуживание», «Партнеру отправлено вознаграждение за кредитный договор»
2. Использовать «Команды», с одной стороны как как элементы бэклога, с другой – API («Назначить встречу», «Перенести встречу», «Подать документ “Предоставление СПД”», «Аннулировать документ»). Появляется соответствие между событиями в бизнесе, командами (действиями), приводящими к этим событиям и бэклогом в единой терминологии в рамках отдельно взятого контекста/домена (так как все-таки контекст является границей существования модели предметной области и терминологии).
Доменный язык дает возможность выбора вариантов реализации. Команда «Подписать ПКБО на обслуживание» при проработке деталей реализации может быть раскрыта как набор элементов бэклога: подписать через ЭЦП, подписать рукой, подписать биометрией, через SMS, кровью.
Отлично же, если у разработки не встают дыбом волосы от фразы «Начислить комиссию за несоблюдение условий бесплатного обслуживания», а тут же находится нужный сервис/API/модуль/… и изменяется его логика, которая так же описана на понятном доменному эксперту языке (в идеале - свой DSL, но это очень дорогое удовольствие и в дикой природе зверь редкий)
С помощью Event Storming можно проводить ретроспективы.
Собираемся командой и с помощью событий восстанавливаем общий контекст. Особенно хорошо рабаотает для анализа длительных активностей.
Ниже пример ретроспективы полугодового проекта. Event Storming помог увидеть отдаленые причины, первичные события, которые в итоге привели к тяжелому релизу. Мы склонны видеть симптомы, снимать симптоматическую «боль», чуть реже нам свойственно и лечить болезнь. Что действительно тяжело, так это оследить каким образом пришли к болезни.
Иногда это носит исключительно исторический интерес, однако в случае итеративных процессов или повторяющихся бизнес-процессов (ну да, тоже итеративных =)))) такой формат ретроспективы особенно полезен:
1. В различные временные интервалы подключались разные люди
2. Из-за временной протяженности работа над проектом даже в глазах одного человека начинает выглядеть и восприниматься как набор атомарных действий
3. Причина и следствие из-за удаленности во времени еле уловимы
Что делаем?
Собираемся, ивент штормим события, выстраиваем их в общий нарратив, цельную историю, проясняем что скрывается за каждым из событий – контекст воссоздан. А дальше уже можем разместить поверх событий «возможности», «болевые зоны», дополнительные метрики, артефакты, все, что может нам помочь достигнуть целей ретроспективы.
Вариант процесса проведение и пример Event Storming на изображениях. Последующие этапы ретроспективы могут быть любыми)
Собираемся командой и с помощью событий восстанавливаем общий контекст. Особенно хорошо рабаотает для анализа длительных активностей.
Ниже пример ретроспективы полугодового проекта. Event Storming помог увидеть отдаленые причины, первичные события, которые в итоге привели к тяжелому релизу. Мы склонны видеть симптомы, снимать симптоматическую «боль», чуть реже нам свойственно и лечить болезнь. Что действительно тяжело, так это оследить каким образом пришли к болезни.
Иногда это носит исключительно исторический интерес, однако в случае итеративных процессов или повторяющихся бизнес-процессов (ну да, тоже итеративных =)))) такой формат ретроспективы особенно полезен:
1. В различные временные интервалы подключались разные люди
2. Из-за временной протяженности работа над проектом даже в глазах одного человека начинает выглядеть и восприниматься как набор атомарных действий
3. Причина и следствие из-за удаленности во времени еле уловимы
Что делаем?
Собираемся, ивент штормим события, выстраиваем их в общий нарратив, цельную историю, проясняем что скрывается за каждым из событий – контекст воссоздан. А дальше уже можем разместить поверх событий «возможности», «болевые зоны», дополнительные метрики, артефакты, все, что может нам помочь достигнуть целей ретроспективы.
Вариант процесса проведение и пример Event Storming на изображениях. Последующие этапы ретроспективы могут быть любыми)
Уже готовлю отдельную статью о заинтерессованных лицах / экспертах в предметке в сугубо прагматичном ключе, в том числе применительно к Event Storming, а пока ответ о том, какого уровня абстракции должны быть события?
Ну то есть, есть же разница между «Заключен договор о поглощении компании» и «Клиент подписал кредитный договор», если речь идет о Банке.
Уровень гранулярности определяется масштабом решаемой задачи и приглашенными на встречу заинтересованными лицами. Если перефразировать предыдущее предложение, то, каких заинтересованных лиц (экспертов в предметной области) мы пригласим зависит от масштаба решаемой задачи, а уровень абстракции/гранулярости событий будет прямо соответствовать уровню абстракции, на котором находятся приглашенные эксперты в предметной области (доменные события должны иметь смысл для эксперта в предметной области, размещающего).
Иными словами, для исследования процесса стратегического инвестирования на уровне группы компаний нужны эксперты в предметной области, для которых релевантен подобный уровень асбтракции. Затем этот высокий уровень может распастся на низлежащие процессы, для проработки которых могут быть задействованы эксперты, работающие на более низком уровне абстракции и так далее [до уровня автоматизации, например, который уже достаточно конкретный =)]
Ну то есть, есть же разница между «Заключен договор о поглощении компании» и «Клиент подписал кредитный договор», если речь идет о Банке.
Уровень гранулярности определяется масштабом решаемой задачи и приглашенными на встречу заинтересованными лицами. Если перефразировать предыдущее предложение, то, каких заинтересованных лиц (экспертов в предметной области) мы пригласим зависит от масштаба решаемой задачи, а уровень абстракции/гранулярости событий будет прямо соответствовать уровню абстракции, на котором находятся приглашенные эксперты в предметной области (доменные события должны иметь смысл для эксперта в предметной области, размещающего).
Иными словами, для исследования процесса стратегического инвестирования на уровне группы компаний нужны эксперты в предметной области, для которых релевантен подобный уровень асбтракции. Затем этот высокий уровень может распастся на низлежащие процессы, для проработки которых могут быть задействованы эксперты, работающие на более низком уровне абстракции и так далее [до уровня автоматизации, например, который уже достаточно конкретный =)]
Forwarded from emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Сервис для коллективной разработки Event Storming и Context Mapping от Vaughn Vernon:
Domain Modeling, Robot!
- https://domorobo.to/
- https://twitter.com/VaughnVernon/status/1443670501235167244?s=20
#DDD #EventStorming #SoftwareArchitecure
Domain Modeling, Robot!
- https://domorobo.to/
- https://twitter.com/VaughnVernon/status/1443670501235167244?s=20
#DDD #EventStorming #SoftwareArchitecure
Twitter
Vaughn Vernon
Take a look at our latest @vlingo_io modeling product. It's currently available as prerelease. - DomoRoboto DoMoRoboto - Hello, Robot! - Thanks, Robot! - Do More, Robot! - Domain Modeling, Robot! #DDDesign #EventStorming #ContextMapping domorobo.to
Forwarded from Микросервисы / распределенные системы
Домен (предметная область) — область знаний/деятельности, для решения проблемы в которой разрабатывается приложение. Размеры домена зависят от того, как выбрать границу.
Как узнать домен?
Вовлекая специалистов, экспертов в домене. Они передают знания о том, почему принимаются те решения, которые принимаются и из каких ключевых элементов состоит домен.
Идея состоит в определении языка, делающего код понимаемым «извне».
Изучение кода новым разработчиком, таким образом, позволяет заодно изучить домен (предметную область).
Изменение в языке ведет к изменению модели и рефакторингу кода.
«If I say a word and I expect that you have the same definition, but you actually have a very different definition, we have false alignment. We think we’re talking about the same thing but we’re not.»
#DDD
Как узнать домен?
Вовлекая специалистов, экспертов в домене. Они передают знания о том, почему принимаются те решения, которые принимаются и из каких ключевых элементов состоит домен.
Идея состоит в определении языка, делающего код понимаемым «извне».
Изучение кода новым разработчиком, таким образом, позволяет заодно изучить домен (предметную область).
Изменение в языке ведет к изменению модели и рефакторингу кода.
«If I say a word and I expect that you have the same definition, but you actually have a very different definition, we have false alignment. We think we’re talking about the same thing but we’re not.»
#DDD
Напишите мне в личку (@sergey486), если вы проводите Event Storming и у вас есть интерес развиваться и развивать эту тему.
Есть идея :)
Есть идея :)