Программирование и повсеместный язык (DDD) в неанглийском домене

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

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

Итак, что меня интересует, так это то, как работать с Ubiquitous Language в неанглийских доменах.

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

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

1. Напишите код, отражающий вездесущий язык на естественном языке домена.
2. Переведите Вездесущий язык на английский и перестаньте общаться на естественном языке домена.
3. Определите таблицу, которая определяет, как повсеместный язык переводится на английский.

Вот некоторые из моих мыслей, основанных на этих опциях:

1) У меня сильное отвращение к смешанному языку, то есть к кодированию с использованием типов / членов / имен переменных и т. Д., Которые не являются английскими. Большинство языков программирования в значительной степени «дышат» английским языком, и большая часть технической литературы, названий шаблонов проектирования и т. Д. Также на английском языке. Таким образом, в большинстве случаев просто невозможно написать код полностью на неанглийском языке, так что вы все равно получите смешанные языки.

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

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

Я уверен, что я не хочу идти на первый вариант, и я думаю, что вариант 3 намного лучше, чем вариант 2. Что вы думаете? Я пропускаю другие варианты?

ОБНОВИТЬ

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

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

Я также обнаружил следующие преимущества, основанные на моем опыте.

• Перевод UL заставляет вас уделять больше внимания определению UL и даже самого домена, особенно когда вы не знаете, как перевести термин, и вам нужно начать просматривать словари и т. Д. Это даже заставило меня пересмотреть решения по моделированию домена. несколько раз.
• Это поможет вам сделать ваши знания английского языка более глубокими.
• Очевидно, ваш код гораздо приятнее смотреть, а не ошеломляюще.

Я часто сталкивался с этой проблемой, и, на мой взгляд, ответ таков: «нет единого ответа, действительного для всех сценариев».

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

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

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

В целом, нас больше интересует, что говорит эксперт по доменам. Поэтому мы хотим упростить им задачу. В противном случае они могли бы просто взять класс UML и прочитать наши диаграммы (это была шутка). Таким образом, единственная реальная рекомендация здесь: «обратите внимание на поведение эксперта по доменам», если они вовлечены в разговор, и разговор идет гладко, вы, вероятно, на правильном пути, придерживайтесь этого языка. Это может привести к небольшой дополнительной работе в команде, но это нормально. Как разработчики, мы несколько обучены изучать слова с определенным значением в контексте.

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

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

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

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

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

Я согласен с комментарием большинства языков программирования «дышать» на английском языке , который всегда становится проблемой при многоязычной разработке

Обычно я хотел бы иметь UL на языке вашей команды программистов

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

например

"количество буа"

По-английски это «Количество дерева» или «Количество дерева», по-французски это «Quantité de Bois», поэтому достаточно близко для обоих ораторов. Это должно уменьшить количество новых слов, которые должен выучить каждый говорящий.

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

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

Недавно я работал над проектом DDD в Швейцарии, где доменом были налоги (в частности, НДС и другой вид налога ... который нелегко перевести на английский язык ...).

Они выбрали первый вариант: UL на немецком языке, также использованный в коде на немецком языке.

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

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

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

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

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

Я не знаю, как бы я сделал эквивалентное имя класса на французском, например, если бы естественным термином было бы «déclaration d'impôts», с противоположным порядком и дополнительным предлогом в середине ... И это просто простой пример. Мне было бы очень интересно, если бы кто-нибудь имел опыт работы с такими именами на латинских языках (французский, испанский, итальянский, португальский ...)!

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

Подчеркнутые символы были в порядке, поскольку на немецком языке все они имеют неакцентированный эквивалент ( ü -> ue и т. Д.). Это еще один момент, когда французы были бы более проблематичными ...