Повсеместный язык - конфликт между правильностью и удобством использования

10

Основной частью Domain Driven Design является последовательное использование повсеместного языка в системе - в разговорах, коде, схеме базы данных, пользовательском интерфейсе, тестах и т. Д.

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

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

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

Это похоже на разумный подход?

documentation domain-specific-languages

— Энди Уэйт
источник

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

— Сокол

1

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

— Калеб Педерсон

7

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

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

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

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

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

— сокол
источник

1

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

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

— Джон Фишер
источник

Хорошо сказано. Это указывает на «проблему Шалтай-Болтай»: слова - это не просто замена, они относятся к вещам, о которых люди знают независимо от слов и их использования. Например, животные понимают идею «температуры». Мы зацикливаемся на словах, когда они являются просто символами понятий. Концепции являются важными вещами.