Full Stack Blog – DDD. Единый язык. Ubiquitous language

10 September 2023

DDD. Единый язык. Ubiquitous language


Статьи серии:

DDD. Что это такое?
DDD. Единый язык. Ubiquitous language

Ubiquitous language - единый язык, который используется для общения членов команды между собой. К членам команды я отношу всех, так или иначе участвующих в разработке: разработчики, тестировщики, аналитики, архитекторы, представители бизнеса, эксперты в предметной области и т.д.

Главная проблема решаемая единым языком - это исключить недопонимание между членами команды.


Далее я постараюсь описать некоторые подробности, идея которых весьма простая: 
собираем словарик терминов и используем его в работе.

Что включать в единый язык?

Термины

В первую очередь заносим в словарь названия сущностей предметной области.

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

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

Процессы

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

Композиция

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

Как собрать данные?

Опросить экспертов. Утвердить у заказчика. Донести до каждого члена команды.
- Кэп

Стоит разработать ясную и предельно простую методология формирования языка. Какие термины включать, как детально описывать, кого опрашивать, как часто делать ревью. Всё это очень зависит от проекта. Разные проекты могут иметь или не иметь роль доменного эксперта, могут решать какую-то проблему для науки или автоматизировать повседневную работу.

Актуализация языка - это постоянный процесс с активно фазой в начале проекта.

Словарь терминов должен быть доступен каждому члену команды, каждый должен знать и использовать его.

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

Будет хорошей практикой периодически возвращаться и актуализировать словарь языка. Также, стоить приучить себя обращать внимание на новые термины в процессе обсуждений.

Как использовать единый язык?

И снова Кэп.

Самое главное - это создание модели, в которой мы обязаны использовать единый язык.

  • Изучаем термины и используем их при общении, на встречах, в переписке.
  • Используем при создании пользовательских историй.
  • Используем в коде. Имена сущностей и процессов нужно брать из словарика.
  • Тестовые сценарии должны пользоваться терминами языка.

Ревью кода и требований будет отличным местом для валидации требования по использованию единого языка. Одобренный PR (pull request) - это гарантия отсутствия в нем неучтенных, новых или неправильных терминов.

Версионирование

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

Не думаю, что преимущества версионирования нужно как-то дополнительно раскрывать :). Версии документа могут предоставить многие системы как Confluence и т.д.

Держать словарь рядом с кодом будет хорошим решением так как это позволит избежать дополнительных таблиц соответствия между версиями реализации и документации.

Общий язык для нескольких проектов

С первого взгляда - это кажется отличной идеей. Мы можем взять и переиспользовать единый язык соседней команды.

Нет сомнений, что на составленное соседней командой нужно посмотреть. Хотя бы для того, чтобы быть уверенным, что ты ничего не пропустил.

Взяв уже готовый язык другой команды мы рискуем работать в домене задачи другой команды, другого проекта, а не в домене нашей задачи.

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

Пример

Задача

Для примера буду использовать следующую задачу:

Автоматизировать работу специалистов по благоустройству в исследовании и описании существующего положения на территории отведенной для проектирования.

Единый язык

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

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

В рамках проекта переведем это как "inspection".

Перечётная ведомость - сопроводительный к дендроплану документ. Здесь указана полная информация о зеленых насаждениях на участке. Учитываются видовые названия, порядковые номера, габариты деревьев и кустарников. Перечетная ведомость также содержит информацию о текущем состоянии насаждений, полученную в ходе обследования территории дендрологами — сухих ветках, заболеваниях, повреждениях.

Так как перечётная ведомость - это отражение существующего положения, то в рамках проекта будем переводить это как "existing plant sheet".

Дендроплан - Топографический план местности, с отдельно нанесенным слоем зеленых насаждений, а также проектом застройки.

Будем использовать такой перевод: "dendroplan".

Дендролог - Специалист по озеленению.

Перевод: "dendrologist".

Растение (plant) разделяется на дерево (tree) и куст (bush).

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

Перевод: "species"

Высота. Не длинна ствола, а высота дерева.

Перевод: "plant height"

Диаметр ствола. Вносим в словарь так как это определенная метрика, которая снимается в определенном месте дерева.

Перевод: "trunk diameter"

Актуализация

Например, на одном из совещаний мы услышали как эксперт говорит инвентаризация зеленых насаждений указывая на перечётную ведомость. Такого в нашем словаре нет. "инвентаризация" звучит как процесс и можно было бы употребить такое в адрес обследования.

В любом случае стоит поговорить с экспертом, выяснить значение и занести в словарь.

Заключение

Тема, предполагающая много воды, выливается в подобную статью.

Нет чётких алгоритмов как создавать единый язык. На эту тему можно много рассуждать или почитать что-нибуть еще. А вот получится хорошо или плохо зависит в конечном счете только от опыта.