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