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

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

Единый язык (на англ. ubiquitous language) – термин, используемый Эриком Эвансом в предметно-ориентированном проектировании (DDD) в практике создания общего языка между разработчиками, экспертами и другими участниками. Он представляет собой общий набор терминов и определений, которые применяют все члены команды во всех аспектах процесса проектирования.

Характеристики единого языка

• Обязательное условие согласованной терминологии – она должна быть построена вокруг модели предметной области.
• Общий язык устраняет неточности и противоречия от экспертов предметной области.
• Единый язык – не деловой язык, навязанный экспертами.
• Он развивается с течением времени, а не определяется полностью за одну встречу.
• Концепции, не являющиеся частью единого языка, отвергаются.
• Самое важное – общая терминология объединяет людей команды проекта.

Процесс создания общего языка

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

В своей книге Вон Вернон предлагает использовать следующие способы создания:

Создание глоссария

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

Создание документации

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

Создание диаграмм физической и концептуальной предметной областей

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

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

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

Проблемы отсутствия единого языка

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

Использование более точного названия

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

Применение термина, который никогда раньше не использовался

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

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

Предложение «просто что-то переименовать»

Представим ситуацию, когда процесс проектирования уже идёт. Короткая фраза с просьбой заменить, например, имя поля в пользовательском интерфейсе может привести к тому, что придётся переименовывать его во всём коде. А это значит, что разработчик потратит время и столкнётся с рисками.

Преимущества и недостатки

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

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