🤮 Когда DDD «не очень» 🤢

Я часто пишу про архитектуру, но для меня это не только про «системы и сервисы». А про управление командами и про то, как мы вместе думаем и договариваемся.

И вот тут уместно поговорить про DDD (domain-driven design). Даже если вы не архитектор, а продакт или аналитик — этот подход помогает лучше понимать бизнес-домен, договориться о терминах и выстроить совместную работу.

Мы часто говорим, что практика «не очень». Но если присмотреться — чаще всего дело не в самой практике, а в том, что мы не научились с ней работать.

Я уже писала большую серию про DDD, а сегодня хочу чуть-чуть поговорить о том, как начинать «играть в DDD».

В финтехе, например, нередко можно услышать мнение, что DDD неприменим. И звучит оно не от случайных людей, а от очень экспертных ребят. Я придерживаюсь противоположного взгляда. Но я противница начинать DDD с самого популярного шага — event storming.

📌 Что такое event storming
Это фасилитированная сессия, на которой команда с помощью стикеров визуализирует ключевые события системы: что произошло → какие команды это вызвало → какие агрегаты в системе реагируют → какие внешние акторы задействованы. В идеале это способ «схватить» доменную модель живьем и быстро вскрыть области незнания.

На практике же есть нюансы!

Минусы event storming на старте
➖ Состав участников: вы собрали людей, но они не обязательно доменные эксперты. И даже не обязательно про нужные домены.
➖ Язык: люди могут использовать одни и те же слова, но вкладывать в них разный смысл. Кажется, что все согласны, а на деле — полный рассинхрон.
➖ Фасилитация: нужен сильный медиатор, и лучше с доменной экспертизой. Иначе он рискует выбесить всех, вмешавшись не в тот момент (например, когда спор наконец-то почти добрался до истины).
➖ Ожидания: многие приходят с установкой «нам что-то расскажут». Никто не готов быть активным участником.
➖ Нет плана: если у вас нет гипотезы или модели, которую вы хотите проверить/доработать, встреча превращается в борщ идей. Брейншторм — это круто, но брейнштормить тоже надо уметь.
➖ Скепсис: часть участников приходит с задачей «обкакать ваш праздник» и играть в «Бабу Ягу против».
➖ Критика ≠ демагогия: нужно уметь отличать конструктивную критику от неконструктивных набросов. Наброс на вентилятор — это не демократия. Это токсичность с примесью демагогии.

👀 Что еще стоит учитывать
Время: event storming легко превращается в многочасовой марафон без ощутимых результатов.
Сложность визуализации: доска со стикерами моментально становится кашей, если нет четкой структуры.
Наследие иерархии: иногда люди боятся говорить, если за столом их руководитель или «великий эксперт». В итоге важные наблюдения остаются невысказанными.
Ложное чувство завершенности: все постояли у доски, всё заклеили стикерами — и появляется ощущение, что «модель готова». Хотя на самом деле все только начинается...

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

А как именно можно начать «играть в DDD» по-другому — расскажу в следующей части.

PS Обратите внимание, что все указанные минусы только про «на старте»!
💬 А у вас есть опыт успешного захода в DDD с event storming? Поделитесь, пжл, что для вас эта практика!

#ddd