A Metrics Suite for Microservices, EventStorming and DDD 👍
Measuring Coupling and Cohesion of Bounded Contexts on an EventStorming Domain Model

https://phillipjohnson.co.uk/a-metrics-suite-for-microservices-eventstorming-and-ddd

На сессии Event Storming мы можем столкнуться с противоречием. Два SME утверждают разное об одном и том же факте.

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

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

В Event Storming противоречие – намек на то, что вы нашли несовместимые концепции в сущности, которую рассматривали до этого как целостную и согласованную.

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

https://agilemindset.ru/что-такое-event-storming/

Еще инструмент подъехал
https://www.msaez.io/

Описание
https://intro.msaez.io/tool/event-storming-tool/

Будем посмотреть.
Судя по описанию оно там как-то умеет сразу в код.

Пришло время вебинаров 🙂

Я заметил, что Event Storming набрал обороты и все в большем числе компаний начинают его применять.
Но нередко изначальная идея теряется.

Напомню, что основная идея – это исследование сложной предметной области и формирование общей ментальной модели между участникоами. Я много выступал сс темой того, что еще можно получить из Event Storming, как можно посотроить микросервисное решение используя эту технику и она стала восприниматься как механизм для построения микросервисов, хотя это в большей степени side effect.

Чтобы построить микросервисное решение не обязательно использовать Event Storming. Можно использовать и другие техники проектирования, Event Storming дает single source of truth в виде Domain Events, которые мы можем обогатить другими метаданными (команды,агрегаты,ограниченные контексты), чтобы получить целевую архитектуру в итоге.

Чтобы получить single source of truth нам нужны эксперты в предметной области, нужны в одном месте, чтобы в диалоге между собой они смогли увидеть различия между пониманием и поведением в рамках одних и тех же процессов и сущностей. То есть избавиться от множественного толкования одних и тех же терминов, поместив конкретные термины в собственные контексты. И вот тогда у нас начнут вырисовываться те самые границы контекстов.

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

Вот может об этом и стоит собрать встречу и пообщаться?

При этом мы вполне можем использовать полученную модель внутри команд разработки, чтобы моделировать компонентную модель, но первичные данные мы получаем от SME (subject matter experts). Альберто называет это «люди с вопросами и люди с ответами». Сверху имено цитата Альберто.

Собрал структурированную базу знаний по микросервисам на основе своих статей и переводов.

https://agilemindset.ru/микросервисы/

11 апреля в 19:00 здесь (telegram) проведу стрим по участникам Event Storming

- кто нужен
- где их искать
- что делать, если не могут
- что делать, если не хотят
- ответы на ваши вопросы

Вопросы можете писать заранее в тред к этому сообщению.

Все готово.

В 19:00 старт, постараемся уложиться в 30-45 минут.

Запись стрима о том, кого приглашать на сессии Event Storming
https://www.youtube.com/watch?v=PVH8RwG9EH4

Miro-доска из стрима
https://miro.com/app/board/uXjVMURLTB4=/?share_link_id=199133005609

В тему этой сессии, если кому-то интересно, то у меня есть практический однодневный курс по теме управления ожиданиями стейкхолдеров, пройдет 29 мая.

Он носит практическую направленность, в течение дня разбираются пять базовых практик:
- Выявление и приоритизация стейкхолдеров
- Формирование экосистемы стейкхолдеров
- Выявление мотивов стейкхолдеров
- Выявление иррациональных мотивов стейкхолдеров
- Создание стратегии коммуникации со стейкхолдерами

Многое из того, о чем говорю в стриме разбираем уже на практике в малых группах.

Для event storming эти знания особенно важны, так как мы помним, что «An Event Storming is only successful if the right people are involved» 🙂

Иногда есть такой этап - этап ревью требований.

На этом этапе задача ревьюеров (разработчиков, тестироващиков) в том числе проверить описанное в документе требований на полноту и непротиворечивость.

Тут есть загвоздка.

Анализ проводил не тот, кто ревьюит, для ревьюера обычно документ требований – это и есть вся информация о требованиях. То есть для него не существует иформации за пределами документа, а значит по-определению для его восприятия описанное в документе будет обладат полнотой.
Чтобы проверить документ требований на полноту, все ревьюеры должны принимать участие в сборе требований, чтобы обладать ровно тем же объемом информации (полнотой понимания), что и человек, подготавливающией документ.
Одна из таких практик, формирующих общий state of the mind, общее понимание предметной области, как раз event storming.

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

По модели, полученной с помощью Event Storming можно определить сложность предметной области. В общем случае – это число событий, Очевидно, если в какой-то модели 1500 событий, то она значительно сложнее модели с 50-ю событиями. Конечно, DDD позволяет нам этой сложностью управлять, мы находим границы поддоменом, формируем ограниченные контексты. И поддомены/ограниченные контексты так же можно оценить по уровню сложости по объему терминов, входящих в границу, событий, команд, сущностей.

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

И вот, обращается клиент, – все медленно, просто жуть, никто ничего не понимает, все по учебнику.

Проводим Event Storming, исследуем предметную область. Она простая, даже отчасти примитивная. Строим карту контекстов и проставляем связи так, как есть сейчас, а сверху накладываем текущую организационную структуру и там просто провал 🙂 Несмотря на простейшую предметку 80% времени уходит на коммуникацию, координацию, управление зависимостями. Фактически – очень простая реорганизация структуры команд должна привести к ускорению почти на порядок (мы пока этого не знаем, потому что все только начинается).

А все дело в том, что было 7 команд и 4 ограниченных контекста (ну так мы построили, не факт, что структура окончательная) и ни одна команда не могла самостоятельно закрыть собой развитие какого-то отельного контекста. То есть всегда требовалось от 2 до всех 7 команд, чтобы внести изменения в один контекст. Это при том, что в 1 команде были компетенции, чтобы полностью поддерживать один из контекстов, но логические границы (зоны ответсвенности/владения, если будет угодно) были установлены так, что они заводили на другую команду доработки.

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

Представьте. Вы - новый сотрудник в компании. Вы садитесь вместе с кем-то, кто в компании давно и он объясняет вам как устроены различные процессы. Вы задаете вопросы, получаете ответы, вопросов остается все меньше.Небольшая часть процессов описана в документах и с ними вы знакомитесь самостоятельно. И вот большую часть процессов вы выполняете не задумываясь.

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

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

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

Та самая цитата еще с 2015-го года.

То, что Альберто «once said», – «в прод идут не знания экспертов в предметной области, в прод идут предположения (assumptions) разработчиков.»

Сравнение Event Storming и Service

Кто хочет немного разобраться в Service Blueprint.

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

1. Основополагающая статья, с нее все началось: https://hbr.org/1984/01/designing-services-that-deliver

2. Более современное описание подхода к созданию Service Blueprint: https://divergentthinking.design/service-design-blueprint-workshop

3. Описание из Open Agile Architecture: https://pubs.opengroup.org/architecture/o-aa-standard/journey-mapping.html

4. Хорошая презентация с описанием: https://static1.squarespace.com/static/5697b3bea2bab855798833c2/t/5c5f828f15fcc09ae50ab741/1549763255171/Blueprint-Workshop+Final+Web.pdf

Финальные аккорды 🧐