DDD и проблема согласования словаря: почему это сложно, но необходимо

31 Mar 2025

В Domain-Driven Design (DDD) один из ключевых принципов — единый язык (Ubiquitous Language), который связывает бизнес, разработку, аналитику и стейкхолдеров. Этот язык формируется через словарь домена, но его создание и поддержка часто становятся сложной задачей.

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

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

Еще одна проблема — длина определений. Если термин описан слишком коротко, в нем могут остаться пробелы или скрытые противоречия. Если слишком подробно — его становится трудно воспринимать. Найти баланс между точностью и удобочитаемостью не всегда просто, особенно если термин связан с разными аспектами системы. Несколько раз в попытка сделать термины точными и выверенными мы получали такие громоздкие формулировки, что становилось сложно их осмыслить. Советую упустить некоторые формальности и оставить более простые варианты.

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

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

Отдельной болью является ситуация, когда аналитики приносят термины от бизнеса и говорят, что они “уже так привыкли” называть. А термины такие либо противоречат тому, что уже у нас есть в словаре, либо звучит криво. Тут нужно приготовиться бороться и искать компромиссы. Уфф….

Как сделать словарь полезным?

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

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