Я знаю, что здесь уже есть некоторые вопросы, которые тесно связаны с этой темой, но ни один из них не использует в качестве отправной точки вездесущий язык, поэтому я думаю, что это оправдывает этот вопрос.
Для тех, кто не знает: Ubiquitous Language - это концепция определения (разговорного и письменного) языка, который в равной степени используется разработчиками и экспертами в предметной области, чтобы избежать несоответствий и недопонимания из-за проблем с переводом и недоразумений. Вы увидите ту же самую терминологию, отображаемую в коде, разговорах между любым членом команды, функциональных спецификациях и еще много чего.
Итак, что меня интересует, так это то, как работать с Ubiquitous Language в неанглийских доменах.
Лично я полностью поддерживаю написание программного кода на английском языке полностью, включая комментарии, но, конечно, за исключением констант и ресурсов.
Однако в неанглийском домене я вынужден принять решение либо:
- Напишите код, отражающий вездесущий язык на естественном языке домена.
- Переведите Вездесущий язык на английский и перестаньте общаться на естественном языке домена.
- Определите таблицу, которая определяет, как повсеместный язык переводится на английский.
Вот некоторые из моих мыслей, основанных на этих опциях:
1) У меня сильное отвращение к смешанному языку, то есть к кодированию с использованием типов / членов / имен переменных и т. Д., Которые не являются английскими. Большинство языков программирования в значительной степени «дышат» английским языком, и большая часть технической литературы, названий шаблонов проектирования и т. Д. Также на английском языке. Таким образом, в большинстве случаев просто невозможно написать код полностью на неанглийском языке, так что вы все равно получите смешанные языки.
2) Это заставит экспертов домена начать думать и говорить в английском эквиваленте UL, что, вероятно, не будет для них естественным, и, следовательно, значительно затруднит общение.
3) В этом случае разработчики общаются с экспертами в предметной области на их родном языке, в то время как разработчики общаются друг с другом на английском языке и, что наиболее важно, они пишут код с использованием перевода UL на английский язык.
Я уверен, что я не хочу идти на первый вариант, и я думаю, что вариант 3 намного лучше, чем вариант 2. Что вы думаете? Я пропускаю другие варианты?
ОБНОВИТЬ
Сегодня, примерно через год, решая эту проблему ежедневно, я должен сказать, что вариант 3 сработал для меня довольно хорошо.
Это было не так утомительно, как я изначально боялся, и перевод в режиме реального времени во время разговора с клиентом тоже не был проблемой.
Я также обнаружил следующие преимущества, основанные на моем опыте.
- Перевод UL заставляет вас уделять больше внимания определению UL и даже самого домена, особенно когда вы не знаете, как перевести термин, и вам нужно начать просматривать словари и т. Д. Это даже заставило меня пересмотреть решения по моделированию домена. несколько раз.
- Это поможет вам сделать ваши знания английского языка более глубокими.
- Очевидно, ваш код гораздо приятнее смотреть, а не ошеломляюще.