Ошибки формирования Ubiquitous Language в подходе Domain Driven Design

Ошибки формирования Ubiquitous Language в подходе Domain Driven Design

В прошлый раз мы обсудили в чем заключается DDD. Теперь давайте обсудим, как избежать ошибок при формировании Ubiquitous Language.

Основные ошибки при формировании Ubiquitous Language

  • Использование технического жаргона: Вместо терминов предметной области, разработчики начинают применять технические термины. Это приводит к разрыву коммуникации между разработкой и бизнесом.
  • Размытые определения: Когда один и тот же термин имеет разные значения для разных участников проекта, это приводит к недопониманию и ошибкам в реализации. Бизнес использует одни термины, а разработчики другие. Часто терминология существует параллельно в разных частях команды.
  • Отсутствие единой терминологии: Разные команды или даже члены одной команды используют разные термины для одних и тех же понятий.
  • Изоляция терминов: Термины существуют только в документации, но не используются в реальной коммуникации. Более того часто в коде они могут называться совсем не связанными терминами.

Признаки проблем с Ubiquitous Language

Коммуникационные:

  • Частые уточнения значений терминов на митингах. Разные члены команды постоянно уточняют, что имеется ввиду, когда говорят о тех или иных терминах.
  • Команда регулярно сталкивается с недопониманиями и спорами по поводу терминов.
  • Конечные пользователи не понимают используемую терминологию и не могут связать ее с реальными бизнес процессами.

Организационные:

  • Сложности в обучении новых участников команды. Новые члены команды не могут быстро разобраться в терминологии и концепциях.
  • Разные команды и разные члены команды используют разные термины для описания одних и тех же сущностей и процессов.
  • Отставание от бизнес процессов. Язык не отражает актуальные изменения в бизнесе.

Архитектурные:

  • В документации используются разные термины, для описания одних и тех же процессов.
  • Бизнес эксперты не понимают и не могут прочитать диаграммы и код. Приходится долго объяснять что имеется ввиду.
  • Документация становится запутанной так как каждая команда интерпретирует одни и теже термины по своему.

Разработка:

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

Как избежать проблем

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

Итого: Ubiquitous Language — это основа DDD. Если его нет, архитектура рушится, код становится неуправляемым, а команда тратит время на бесконечные уточнения. Следите за признаками и вовремя корректируйте язык!

Мой канал в telegram

1
Начать дискуссию