В DDD одним из главных подходов в проектировании модели является ubiquitous language (общеупотребительный язык). Под общеупотребительным языком понимается набор терминов, которые являются базовыми в предметной области, и часто напрямую транслируются в сущности проектируемой модели. Общеупотребительный язык, как и следует из термина, должен являться общим для всех: для группы разработчиков, для группы экспертов предметной области, для заказчика.
Но в языках отличных от английского это ведет к проблеме. Термины для модели, используемые разработчиками, будут отличатся от терминов экспертов предметной области и заказчика. Разработчики должны будут иметь список соответствия (вида Б = B) терминов и объектов модели. При этом все разработчики, участвующие в проектировании модели, а в идеале все участвующие в разработке, должны иметь единый список. То есть простой перевод терминов не поможет, так как многие слова могут иметь различное значение, и могут по разному быть интерпретированы разными членами команды. А это уже нарушение принципа ubiquitous language, так как язык становится уже не общим.
Отсюда же вытекает вторая проблема – несоответствие предметных областей. В языке описания модели может не быть терминов для той предметной области которая описывается на языке общения экспертов предметной области.
Как правильно решаются эти проблемы я не знаю. Я столкнулся с этим вопросом во время чтения книги Эрика Эванса (Eric Evans) “Domain-Driven Design: Tackling Complexity in the Heart of Software”.
В нашей компании существует посредник между разработчиками и специалистами по предметной области. В своей книге, Эванс, говорит о том, что использование посредника-аналитика, как в водопаде, ведет к отсутствие обратной связи. По сути аналитик, общаясь с экспертами, один отвечает за проектирование модели, при этом упуская сторону разработчиков в проектирование. Модель сильно отличается от реальности, и зачастую требуется корректировка модели с учетом возможности разработки этой модели, представлении в виде кода.
У нас аналитик, после обсуждения со специалистами по предметной области, заново все обсуждает с разработчиками. Это значительно увеличивает время проектирования модели, а так же сводит четкое понимание к узкому кругу лиц, которые напрямую участвуют в проектировании. Простые разработчики увеличивают свое понимание лишь в момент преступления к разработке определенного функционала. Замечу, что мы используем DDD, но не domain-driven design, а data-driven design.
В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.
