🧠 Что дает DDD на этапе сбора требований и всех этапах взаимодействия с бизнесом?

1. Сбор требований — это не просто список хотелок
В DDD важно не просто услышать, что «нужно сделать кнопку», а понять, в каком домене живет эта кнопка, какую бизнес-ценность она несет, и какой словарь у людей, которые ее хотят.
Наша задача — достроить ментальную модель бизнеса, а не просто получить бэклог.
🧩 Инструменты: Event Storming, Domain Storytelling, бизнес-интервью на основе Ubiquitous Language.

2. Единый язык (Ubiquitous Language)
Если у разных ролей (аналитики, архитекторы, продакты, пользователи) — разный словарь, проект обречен на баги из-за недопонимания.
Именно на этапе сбора требований надо:
— фиксировать термины, особенно амбигуозные (например, «клиент» может быть и физлицом, и юридическим лицом, и API-интегратором)
— называть вещи бизнес-словами, а не «экран 3», «процесс 5», «где-то там фильтр»
— не бояться обсуждать, что такое “правильно” в глазах бизнеса
🎯 DDD здесь учит нас: не просто спросить “что сделать”, а выяснить “какое поведение считается корректным” и “почему именно так”.

3. Проектирование — это уже часть коммуникации
На этапе общения с бизнесом может (и должно!) рождаться проектное мышление:
— а как это будет разделено на bounded context-ы?
— это новая подсистема или расширение существующей?
— а эта функция — чей юрисдикции, какого домена?
⛓️‍💥DDD позволяет сразу задать границы, чтобы избежать каши из связей и зависимостей в будущем.

4. Поиск доменных экспертов — не пункт в чеклисте, а процесс
Если вам повезло и у вас есть живой domain expert — берегите его! Но чаще всего их приходится выращивать внутри компании.
DDD говорит: доменный эксперт — это не титул, а функция.
Это может быть продакт, клиент, юрист, кастомер-саппорт — тот, кто лучше других понимает бизнес-правила в конкретной области.
🧩 На этапе сбора требований это значит:
— слушать больше,
— задавать наводящие вопросы,
— и замечать, кто из собеседников реально может объяснить, почему система устроена именно так.

5. Где сложности?
💭 Бизнес не привык мыслить через модели. Ему нужно «чтобы работало», а не «bounded context с единым языком».
🤢 Слово “домен” часто вызывает отторжение. Его путают с “сферой” или ДАЖЕ “базой данных”.
🤝 Нет привычки к коллаборации. Распространена модель «продукт пишет ТЗ → разработка делает».
DDD требует совместного проектирования.

6. Коллаборация — главный инструмент
Если на этом этапе вы не сделали язык совместным, никакой code-first не спасет.
Поэтому:
– Стенормьте встречи с разными ролями
– Пробуйте фасилитации (Event Storming прекрасно заходит с бизнесом)
– Делайте схемы, рисуйте!
– И фиксируйте все: термины, допущения, ограничения, цели

Следующий пост (завтра) — про архитектуру и проектирование.
💬 А пока расскажите: на вашем проекте язык между командами был единым? Или каждый понимал по-своему?

#architecture #ddd