В 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. То есть разработчики имеют свою терминологию, а специалисты предметной области свою. Посредник, наше бутылочное горлышко, является связующим звеном.
Здравствуйте, 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 минут, хотя бы на верхних уровнях.
Здравствуйте, nvb, Вы писали:
nvb>Здравствуйте, Saddo, Вы писали:
>Вообще-то подобная проблема решается словарем — грубо говоря, текстовыми заметками, прикрепляемыми к блокам модели и однозначно интерпретирующими короткое название блока в понятном для всех виде. Можно иметь несколько интерпретаций, понятных для заказчика и исполнителей, но писать эти интерепретации должен один человек — аналитик. Это хуже, но если иначе нельзя... >>Разработчики должны будут иметь список соответствия (вида Б = B) терминов и объектов модели.
Я примерно о том же и говорил.
>>Отсюда же вытекает вторая проблема – несоответствие предметных областей. В языке описания модели может не быть терминов для той предметной области которая описывается на языке общения экспертов предметной области. >Это как??? Хочется спросить "тогда зачем нужна такая модель?", но вероятно, все сложнее. Приведите пример такого несоответствия.
Прямой пример я навскидку не смогу привести. Но наверное есть термины специфичные исключительно для русского языка (язык предметной области) и не имеющие аналогов в английском (язык модели). Хотя в популярных предметных облостях это не бывает.
nvb>Стоп! В последнем предложении две фразы: nvb>"Модель сильно отличается от реальности" — так приблизьте до необходимого уровня, что мешает? Все модели не идеальны. nvb>"Зачастую требуется корректировка модели с учетом возможности разработки этой модели, представлении в виде кода" — коректировка или дальнейшая декомпозиция?
Аналитик, который занимается анализом предметной области, может не всегда идеально представить свое знание ввиде модели. И не всегда его модель будет хорошей, если не будет учитываться мнение тех кто будет разрабатывать эту модель.
nvb>Вообще, похоже, есть проблемы с аналитиком, раз сказана такая фраза. У него времени не хватает или он просто не в состоянии это сделать?
"In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback. The analysts have full responsibility for creating the model, based only on input from the business experts. They have no opportunity to learn from the programmers or gain experience with early versions of software. Knowledge trickles in one direction, but does not accumulate." (c) Evans
nvb>Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили? nvb>И почему разработчики не участвуют в проектировании? Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили?
Просто подобный слой приносит сильные задержки по времени. Эксперт <-> Аналитик(и) <-> ТимЛид/Проектировщики. К тому же, как и любая прослойка вносит свой уровень шума и сломанного телефона.
nvb>А вообще-то я немного не понимаю, в чем проблема. Если в работе над моделью принимают участие лишь несколько аналитиков, то именно они и будут являться носителями ключевых знаний. Если Вас не устраивает такое состояние дел, то можно организовать регулярные семинары для разработчиков, на которых будет объясняться модель — что там есть и зачем. Но, по опыту, большинству разработчиков это настолько по барабану, что такой семинар — пустая трата времени и денег. Лучше уделять время на объяснение модели на проектных совещаниях — по 10-15 минут, хотя бы на верхних уровнях.
В том-то и проблема, что у нас это единственное похоже решение.
Здравствуйте, Saddo, Вы писали:
nvb>>Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили? nvb>>И почему разработчики не участвуют в проектировании? Или Ваша фраза "аналитик заново все обсуждает с разработчиками" означает лишь выдачу задания и проверку, правильно ли они его уяснили? S>Просто подобный слой приносит сильные задержки по времени. Эксперт <-> Аналитик(и) <-> ТимЛид/Проектировщики. К тому же, как и любая прослойка вносит свой уровень шума и сломанного телефона.
Уже много всего мы написали. Попробую избежать ухода в мультитопиковость
Давайте создадим модель проблемы, которую Вы хотите решить Для начала, в виде декомпозированного списка, в котором элементы не связаны друг с другом (будем есть слона по кусочкам).
1. Аналитики не всегда могут корректно перевести англоязычные термины
2. Аналитики не могут создать модель, с достаточной степенью приближения отображающую реальность
3. Время, затрачиваемое на реализацию бизнес-требований заказчика, увеличивается вследствие трех-четырех этапного процесса реализации (эксперт-аналитики-тимлид-проектировщики)
4. Вследствие того, что программисты-исполнители не участвуют и не хотят участвовать в создании модели, есть риск возникновения проблем с реализацией этой модели.
Это все? Можно дополнить.
Теперь давайте попробуем реализовать эту модель в виде стандартных решений для каждого пункта
1. Зачем переводить одно английское слово одним русским словом? Переведите десятью, поставьте гипертекстовые ссылки на термины и т.п. В общем, создайте словарь.
2. Пусть аналитики проведут несколько этапов анализа и синтеза необходимых элементов модели для получения достаточной степени приближения.
3. С этим ничего не поделаешь. Рядовые программисты не могут по умолчанию работать системными аналитиками. Но попробуйте подойти к проблеме с противоположной стороны. Представьте, что все программисты смогли бы это делать. Тогда бы они предпочли только этим и заниматься, откладывая написание кода на потом, пока не нашли бы действительно идеальное решение (к тому же еще и устраивающее их всех). Это ведет к срыву сроков и претензиям заказчика. Сравните с существующей сейчас у Вас и работающей трехступенчатой схемой. Вы все еще уверены, что хотите поменять ее? Как сказали в соседней ветке — посадите рядом десять Линусов Торвальдсов и получите такую массу проблем, что Вам и не снилась
4. Вот тут уже труднее. Посоветовать ничего не могу – сильно зависит от конкретных людей и организации. Можно тянуть за уши к свету всех на тренингах и совещаниях, можно не всех, а только тимлидов или старших программистов. Можно декомпозировать модель до уровня, касающегося непосредственно исполнителей и предложить им самим декомпозировать дальше. Можно хотя бы попросить документировать проблемы, которые они видят при реализации этой модели (охаять чужое творение всякий рад ) Конечно, идеальное решение здесь – повышать командную сплоченность, тогда все участники будут сами принимать активное участие в обсуждении модели, но это труднее всего вышеперечисленного. Кстати, при этом сильно уменьшится время из п.3,
Конечно, я не верю в то, что это все — в яблочко, и поможет вот прямо завтра решить все проблемы Это всего лишь иллюстрация того, каким путем можно пойти.
Собственно, так и поступают приглашенные консультанты — раскладывают проблемы на доступные их пониманию независимые кусочки и фиксят эти кусочки стандартными, известными им методами. Затем проводится следующая итерация. Попробуйте сделать то же сами — Вы ведь лучше их знаете свою специфику
Здравствуйте, Saddo, Вы писали:
S>В DDD одним из главных подходов в проектировании модели является ubiquitous language (общеупотребительный язык)..... S>..... Замечу, что мы используем DDD, но не domain-driven design, а data-driven design. ...... S>В нашем случае мы избавились от проблем просто отказавшись от ubiquitous language используемого в DDD. S>Как эти проблемы решается в других компаниях?
Так что же это за "DDD" на которое Вы ссылаетесь названии темы?
И если это "data-driven design", то:
1. что именно Вы назывете этим термином? давайте ссылку
2. а пока не прояснено №1, то и нафик непонятно какое место там имеет ubiquitous language (общеупотребительный язык), и соответственно как чей-либо опыт к Вам вообще относится.
Здравствуйте, ilya.buchkin, Вы писали:
IB>Так что же это за "DDD" на которое Вы ссылаетесь названии темы?
Domain Driven Design. Простите, забыл поставить ссылку. В оригинальном посте, в моем блоге, я поставил ссылку. Но там мало кто читает, поэтому я скопировал вопрос сюда, а ссылку не поправил.
Здравствуйте, nvb, Вы писали:
nvb>Давайте создадим модель проблемы, которую Вы хотите решить Для начала, в виде декомпозированного списка, в котором элементы не связаны друг с другом (будем есть слона по кусочкам).
nvb>1. Аналитики не всегда могут корректно перевести англоязычные термины nvb>2. Аналитики не могут создать модель, с достаточной степенью приближения отображающую реальность nvb>3. Время, затрачиваемое на реализацию бизнес-требований заказчика, увеличивается вследствие трех-четырех этапного процесса реализации (эксперт-аналитики-тимлид-проектировщики) nvb>4. Вследствие того, что программисты-исполнители не участвуют и не хотят участвовать в создании модели, есть риск возникновения проблем с реализацией этой модели.
nvb>Это все? Можно дополнить.
2) —
1)Нет, проблема не в переводе аналитика. Все таки дело в том что аналитик один не может полностью спроектировать модель без участи разработчиков (в частиности проэктировщиков, тимлидов, etс)
3)Да, самое прискорбное
4)Да, но чаще рядовые программисты исполнители редко имеют большое значение. Скорее речь о сеньер девелоперах, которые реализуют базовую часть приложения: модель, инфраструктуру.
nvb>Теперь давайте попробуем реализовать эту модель в виде стандартных решений для каждого пункта
nvb>1. Зачем переводить одно английское слово одним русским словом? Переведите десятью, поставьте гипертекстовые ссылки на термины и т.п. В общем, создайте словарь.
На данный момент словарь единственный выход. Так фактически у нас сейчас и есть. nvb>2. Пусть аналитики проведут несколько этапов анализа и синтеза необходимых элементов модели для получения достаточной степени приближения. nvb>3. С этим ничего не поделаешь. Рядовые программисты не могут по умолчанию работать системными аналитиками. Но попробуйте подойти к проблеме с противоположной стороны. Представьте, что все программисты смогли бы это делать. Тогда бы они предпочли только этим и заниматься, откладывая написание кода на потом, пока не нашли бы действительно идеальное решение (к тому же еще и устраивающее их всех). Это ведет к срыву сроков и претензиям заказчика. Сравните с существующей сейчас у Вас и работающей трехступенчатой схемой. Вы все еще уверены, что хотите поменять ее? Как сказали в соседней ветке — посадите рядом десять Линусов Торвальдсов и получите такую массу проблем, что Вам и не снилась
Нет, я не говорю о всех программистах ) В этом естественно нет смысла
Речь о тех кто реализуют базовую часть приложения: модель, инфраструктуру. А рядовые программисты иногда активно против вникания в это все.
nvb>4. Вот тут уже труднее. Посоветовать ничего не могу – сильно зависит от конкретных людей и организации. Можно тянуть за уши к свету всех на тренингах и совещаниях, можно не всех, а только тимлидов или старших программистов. Можно декомпозировать модель до уровня, касающегося непосредственно исполнителей и предложить им самим декомпозировать дальше. Можно хотя бы попросить документировать проблемы, которые они видят при реализации этой модели (охаять чужое творение всякий рад ) Конечно, идеальное решение здесь – повышать командную сплоченность, тогда все участники будут сами принимать активное участие в обсуждении модели, но это труднее всего вышеперечисленного. Кстати, при этом сильно уменьшится время из п.3,
На данный момент наверное это первый более или менее командный проект у нас. Командная сплоченность проблема, и скорее всего мы прибегаем к плотной декомпозиции. Каждый знает только о том что пишет.
nvb>Конечно, я не верю в то, что это все — в яблочко, и поможет вот прямо завтра решить все проблемы Это всего лишь иллюстрация того, каким путем можно пойти.
=^__^=
На данный момент, так как мы не используем Domain Driven Design как таковой, вышеприведенные решения которые приняты у нас работают. Просто, в связи изучением книг по данной практике разработки и дизайна, хотелось знать что делают те кто придерживаются этой практики
Сейчас, используя Data Driven Design, модель имеет более 100 сущностей (исключительно анемичных, использующихся для передачи данных). При этом модель постоянно совершенствуется. Используется словарь терминов (в виде двух человек у который можно уточнить соответсвие терминов в ТЗ, с моделью %)), а так всего один человек как связка между разработчиками и бизнес экспертами заказчика. Плюсом у нас то что, аналитик занимается так же проектированием, и не далек от кода. Минус — он не один проектирует, и это все ведет к "эксперт-аналитики-проектировщики".
Здравствуйте, Saddo, Вы писали:
S>На данный момент, так как мы не используем Domain Driven Design как таковой, вышеприведенные решения которые приняты у нас работают. Просто, в связи изучением книг по данной практике разработки и дизайна, хотелось знать что делают те кто придерживаются этой практики
S>Сейчас, используя Data Driven Design, модель имеет более 100 сущностей (исключительно анемичных, использующихся для передачи данных). При этом модель постоянно совершенствуется. Используется словарь терминов (в виде двух человек у который можно уточнить соответсвие терминов в ТЗ, с моделью %)), а так всего один человек как связка между разработчиками и бизнес экспертами заказчика. Плюсом у нас то что, аналитик занимается так же проектированием, и не далек от кода. Минус — он не один проектирует, и это все ведет к "эксперт-аналитики-проектировщики".
Я все пытаюсь убрать лишнюю сущность, а Вы опять пытаетесь ее добавить
Да, проблема вполне понятна. В Вашей компании хотят перейти от DataDD к DomainDD. Для этого необходимо перенести фокус внимания возможно большего числа членов команды с уровня реализации хотя бы на уровень модели, потому что это — ключевая точка для перехода. В первую очередь это касается сеньоров и тимлидов, потому что без них переход не удастся осуществить в принципе. Так?
Вы в первоначальном посте изложили проблемы, которые встали перед компанией или проектом при этом переходе. Эти проблемы не являются особенностью DomainDD. Любой руководитель проекта, если у него есть голова на плечах, заботится о том, чтобы команда проекта видела задачу (в Вашем случае — модель) в целом и согласовывала свою работу с этим видением. При необходимости его корректируя. Это повышает мотивацию на результат, снижает риски — в общем, сплошные плюсы, откуда не взгляни. Если же в проекте таких людей мало — то эти люди становятся перегружены со всеми вытекающими, что ведет к необходимости введения дополнительных уровней иерархии.. ну и так далее.
А теперь скажите — решение перечисленных и поправленных Вами 4-х пунктов реально приблизит Вашу компанию к переходу на DomainDD?
И что с того, что они являются общими для всех проектов? Или Вы ищете "Пятый элемент", специфичный для DomainDD, с помощью которого удастся обойтись без решения этих пунктов? Или хотя бы имеющий большее значение, чем эти четыре?
nvb>Да, проблема вполне понятна. В Вашей компании хотят перейти от DataDD к DomainDD. Для этого необходимо перенести фокус внимания возможно большего числа членов команды с уровня реализации хотя бы на уровень модели, потому что это — ключевая точка для перехода. ... nvb>... Эти проблемы не являются особенностью DomainDD. ... nvb>А теперь скажите — решение перечисленных и поправленных Вами 4-х пунктов реально приблизит Вашу компанию к переходу на DomainDD? nvb>И что с того, что они являются общими для всех проектов? Или Вы ищете "Пятый элемент", специфичный для DomainDD, с помощью которого удастся обойтись без решения этих пунктов? Или хотя бы имеющий большее значение, чем эти четыре?
Разве в "management" общаются на религиозные темы?
Здравствуйте, nvb, Вы писали:
nvb> В Вашей компании хотят перейти от DataDD к DomainDD.
Каша какая-то... Причем здесь DDD?
По описанию Agile vs RUP-какой-нибудь, что ортогонально тому, какая архитектура у проекта.
В случае Agile заказчик сам вовлекается в процесс разработки, что, по идее, убирает завязанность на аналитика. С другой стороны, с точки зрения здравого смысла — это полная фигня, так как пока нет одного человека, который четко скажет "заказчик на самом деле имел ввиду вот это", будет полный бардак. И не важно кто этим человеком будет — аналитик или представитель заказчика.
И, еще раз — это все имеет весьма опосредованное отношение к архитектуре, хотите писать в терминах заказчика — создавайте соответсвующий DSL и вперед. Никакая объектная модель, будь она хоть сто раз Domain Driven, не уберет разницу между реальной предметной областью и вашим представлением о ней.
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, nvb, Вы писали:
nvb>> В Вашей компании хотят перейти от DataDD к DomainDD. IB>Каша какая-то... Причем здесь DDD? IB>По описанию Agile vs RUP-какой-нибудь, что ортогонально тому, какая архитектура у проекта.
Фраза вроде бы правильная, даже возразить нечего... и что?
IB>В случае Agile заказчик сам вовлекается в процесс разработки, что, по идее, убирает завязанность на аналитика. С другой стороны, с точки зрения здравого смысла — это полная фигня, так как пока нет одного человека, который четко скажет "заказчик на самом деле имел ввиду вот это", будет полный бардак. И не важно кто этим человеком будет — аналитик или представитель заказчика.
Даже отвечать не буду на это утверждение — ответят и без меня Что сейчас начнется — подумать страшно...
IB>И, еще раз — это все имеет весьма опосредованное отношение к архитектуре, хотите писать в терминах заказчика — создавайте соответсвующий DSL и вперед. Никакая объектная модель, будь она хоть сто раз Domain Driven, не уберет разницу между реальной предметной областью и вашим представлением о ней.
А вот эту фразу лучше было написать в ответ на первоначальный вопрос Ибо здесь уже идет разговор о том, что проблема кроется, как всегда, в людях, а не в процессах.
Здравствуйте, Saddo, Вы писали:
S>Отсюда же вытекает вторая проблема – несоответствие предметных областей. В языке описания модели может не быть терминов для той предметной области которая описывается на языке общения экспертов предметной области.
Я сейчас ужасную крамолу скажу. В общем случае, представления разных людей об одной и той же предметной области не совпадают. Для любой сложной системы, предметная область зависит от точки зрения. Возьмем, к примеру, морской порт. Логистики воспринимают его в теринах грузопотоков и хранилищ. Инженеры, воспринимают его в терминах сооружений и механизмов. Бухгалтера -- в терминах прихода и расхода. Служба безопасности, юридическая служба, профсоюз грузчиков, экологи, даже портовые крысы -- все они воспринимают одни и те же объекты с разных точек зрения.
У программистов ровно то же самое. Чем сложнее проект, тем больше различие в точках зрения.
S>Как эти проблемы решается в других компаниях?
Я знаю два варианта.
1. Программисты становятся экспертами в предметной области. По крайней мере те, которые занимаются проектированием. Решается посредством обучения. Дорого, эффективно, распространено.
2. Составляется онтология предметной области, сводящая воедино разные точки зрения. Т.е. явно показывающая, что кран бухгалтера и кран инженера это один и тот же объект, но их точки зрения на него отличаются такими-то аспектами. Сложно, дорого, нераспространено.
Здравствуйте, nvb, Вы писали:
nvb>Фраза вроде бы правильная, даже возразить нечего... и что?
И все. Вы разберитесь сначала о чем речь, об Agile или о DDD.
Здравствуйте, IB, Вы писали:
nvb>>Фраза вроде бы правильная, даже возразить нечего... и что? IB>И все. Вы разберитесь сначала о чем речь, об Agile или о DDD.
Других вариантов нет? "Вы подпишете это договор сейчас или вечером?"
Мне-то это зачем? Я писал, что проблемы общие, независимо от названия процесса. И Вы, кстати, тоже, хотя и про другие проблемы.
А доказывать тут, что это ни разу не Agile и Agile не станет — мне время жалко, бодяга на десять постов растянется
Здравствуйте, nvb, Вы писали:
nvb>Других вариантов нет? "Вы подпишете это договор сейчас или вечером?"
Других нет, если конечно хочется до чего-то договориться, а не просто так потрындеть. В последнем случае действительно пофиг о чем.
nvb>Мне-то это зачем?
То есть, тебе все равно о чем речь, все равно про свое напишешь? Нормальный подход =)
nvb>Я писал, что проблемы общие, независимо от названия процесса.
А я писал, что DDD к этим проблемам не имеет никакого отношения.
Здравствуйте, IB, Вы писали:
nvb>>Других вариантов нет? "Вы подпишете это договор сейчас или вечером?" IB>Других нет, если конечно хочется до чего-то договориться, а не просто так потрындеть. В последнем случае действительно пофиг о чем.
Договориться до чего? Заставить тебя признать мою точку зрения на название процесса? Учитывая твой опыт, у меня это займет очень много времени и усилий, с совершенно негарантированным результатом А если учесть, что топикстартер наверняка описал свой процесс не исчерпывающе, то и вовсе смешно получается.
nvb>>Мне-то это зачем? IB>То есть, тебе все равно о чем речь, все равно про свое напишешь? Нормальный подход =)
Я дал совет, исходя из вопросов. Если человек пошел на красный свет и его сбила машина, то причина этого — в неправильном переходе улицы, а не в марке машины. Марка тоже, конечно имеет значение, но она вторична. Процесс разработки вторичен в данной ситуации. Ну хорошо, я заявляю, что считаю процесс тяжелым, типа RUP. Что изменилось? Ничего. Теперь примем твою (?)точку зрения — это Agile. Что изменилось? Пока тимлиды с сеньорами будут класть на архитектуру (модель), в разработке по обоим процессам будут проблемы. Пока нет единой терминологии (словаря) для заказчиков и исполнителей — будут проблемы.
nvb>>Я писал, что проблемы общие, независимо от названия процесса. IB>А я писал, что DDD к этим проблемам не имеет никакого отношения.
Иван, я читал твои статьи и осознаю, что в процессах разработки ПО ты разбираешься лучше меня, но, похоже, ты сегодня не с той ноги встал
nvb>Теперь примем твою (?)точку зрения — это Agile. Что изменилось? Пока тимлиды с сеньорами будут класть на архитектуру (модель), в разработке по обоим процессам будут проблемы. Пока нет единой терминологии (словаря) для заказчиков и исполнителей — будут проблемы.
nvb>>>Я писал, что проблемы общие, независимо от названия процесса. IB>>А я писал, что DDD к этим проблемам не имеет никакого отношения.
В проектной группе обычно не только разработчики. А всем остальным, кроме разработчиков, на архитектуру совершенно обоснованно насрать.
Архитектура с процессом очень мало связаны.
Ты в этом форуме, потому что тебя интересует управление, а значит архитектура приплетена совершенно зря. Иначе все дружно перемещаемся в DESIGN.
Здравствуйте, VGn, Вы писали:
nvb>>Теперь примем твою (?)точку зрения — это Agile. Что изменилось? Пока тимлиды с сеньорами будут класть на архитектуру (модель), в разработке по обоим процессам будут проблемы. Пока нет единой терминологии (словаря) для заказчиков и исполнителей — будут проблемы.
nvb>>>>Я писал, что проблемы общие, независимо от названия процесса. IB>>>А я писал, что DDD к этим проблемам не имеет никакого отношения.
VGn>В проектной группе обычно не только разработчики. А всем остальным, кроме разработчиков, на архитектуру совершенно обоснованно насрать.
Угу. Всем. Включая РMа с аналитиками. И тестлида А вообще, это печально, потому что в большинстве проектов это действительно так.
VGn>Архитектура с процессом очень мало связаны. VGn>Ты в этом форуме, потому что тебя интересует управление, а значит архитектура приплетена совершенно зря. Иначе все дружно перемещаемся в DESIGN.
А можно мы сами решим? Ну пожаааалуйста...
Архитектура тут совершенно не при чем, непонятно, почему ты решил, что я на ней фокусируюсь. Я писал про отношение лидов к принятию архитектурных решений, какие бы ни были эти решения и какой бы не был процесс разработки.
А вообще я заканчиваю с этой веткой, поскольку мы ушли далеко в сторону и дальнейшее топикстартеру, думаю, уже неинтересно, а меряться, у кого интеллект длиннее — времени жаль.
) Конечно, идеальное решение здесь – повышать командную сплоченность, тогда все участники будут сами принимать активное участие в обсуждении модели, но это труднее всего вышеперечисленного. Кстати, при этом сильно уменьшится время из п.3, 
Мы уже победили, просто это еще не так заметно...
