Понавыдумывали себе процессов

Одно из основных возражений, которые я слышу, это: «У нас нет DDD, нам это не подходит».
Понимаю, откуда оно. Техника плотно проросла в DDD-сообществе, в статьях про неё сразу идут bounded contexts и агрегаты, а на конференциях её показывают люди, которые пришли туда с докладом про тактические паттерны. Но это заблуждение.

Что ES делает на самом деле

Он не моделирует домен, а вскрывает расхождения между тем, как люди думают о системе. DDD - это один из способов потом эти расхождения оформить: выделить контексты, договориться про ubiquitous language, нарезать границы. Если у вас монолит и вы не собираетесь его резать, ES всё равно покажет, где в этом монолите проходят настоящие швы. Знать про них полезно, даже если резать вы будете через два года или никогда.

ES работает и без DDD

- Разбор инцидента, который повторяется. Если система разрослась, а в команде никто не может на 100% уверенно аллоцировать корень проблемы, ES может помочь его найти. Раскладываем по стене реальную последовательность событий. Не то, как должно быть по документации, а как было на самом деле. Обычно выясняется, что участники разных команд держали в голове разные версии одного и того же процесса, и дырка была ровно на стыке.
- Наследство, в котором никто не разбирается целиком. На самом деле, схожий кейс с первым вариантом. Классика: систему писали N лет, авторы ушли, в команде каждый знает свой кусок. И тут стена стикеров - самый быстрый способ собрать эти куски вместе. Быстрее, чем читать код, и надёжнее, чем читать вики.
- Оценка большой доработки. Прежде чем оценивать, разложите процесс по событиям и отметьте, какие из них меняются. Часто оказывается, что «небольшая фича» задевает четыре команды. Так было и у меня, когда моя команда в легаси системах хотела внедрить новую механику монетизации. Короткое приключение на 20 минут в итоге задевало добрую часть системы, могло приводить к потерям и тд. Хорошо, что мы это выяснили ДО, а не после.

Связь с ценой владения

Не так давно я писал про четыре цены разработки - Build, Run, Change, Exit. ES бьёт по третьей и четвёртой.
Неправильно проведённая граница между сервисами не болит на этапе Build. Она болит потом - каждое изменение задевает несколько сервисов, каждый релиз требует координации, каждая попытка что-то вывести из эксплуатации упирается в чужие зависимости. День работы со стикерами против года распределённого монолита. Арифметика неприятная, но очевидная.

Значит ли это, что ES гарантирует правильные границы? Нет, не гарантирует. Он гарантирует только то, что разговор про границы произойдёт до написания кода, а не после.

Где ES не нужен

ES - дорогой процесс, который требует нескольких часов сосредоточенной работы команды. Если у вас команда из трёх человек, которая пилит несложную систему вместе с фаундером, который берет на себя роль продакта, то это ритуал ради ритуала. Проблема тут будет скорее не в понимании домена, а в гигиенических вещах: например, в отсутствии тестов или в чистоте постановки задач. ES их не вылечит, зато красиво замаскирует под «мы поработали над архитектурой».

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

#eventstorming #процессы #разработка