Сорри за слегка ламерский вопрос.

Дошли руки до изучения матчасти — книжек товарищей-гуру о конкретных методологиях.

Очень забавно одновременно читать введения в XP/RUP/MSF/DDD и пытаться отделить принципиальные отличия от несовпадений в терминологии.

Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований? На основе требований разрабатывается конкретные юз-кейсы — из них получаются диаграммы классов, а там уже и до архитектуры недалеко. Не, различия есть, в UP весьма приветствуются тома экспертного анализа, а в XP — бог-заказчик. Но есть такое ощущение, что во всех приводимых примерах архитектура, разбивка на классы и т.п. проектируется исходя из требований к продукту, без учёта реализации или без учёта возможных изменений или вообще с рекомендацией забить на планирование, потому что а) фиг угадаешь и б) если будешь делать всё правильно, стоимость изменений будет линейной, расслабься

Конечно, я намеренно передёргиваю. Но вот Эрик Эванс (который DDD) мягенько так ругает остальных товарищей, что дескть нехорошо обижать предметную область (вообще-то он использует термин domain), она ведь самая главная и вообще давайте жить дружно и использовать одну общую концептуальную модель. И что нехорошо вообще-то строить проектпо самой нестабильной информации. Ибо требования меняются постоянно, а вот архитектура как заложена в самом начале, так и не избавишься... В то же время, сам Эрик Эванс тоже не гнушается рисовать use-case и тащить бизнес-логику в доменную модель.

В общем что-то тут не так. Чую, но обосновать не могу (с)Каганов.

Здравствуйте, Sinix, Вы писали:

S>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований?

Архитектура (программного обеспечения) – это совокупность согласованных технических решений направленная на удовлетворение требований, предъявляемых к программному обеспечению.
Т.е. архитектура — есть функция требований. Это аксиома.

Но есть второй аспект — инженерный.
Допустим, есть у нас требования создать устройство для сиденя, то есть — табуретку. Табуретка штука простая, но сделать мы ее можем разными способами. Можем: а) сколотить гвоздями, б) соединить детали в шип на клею, в) использовать современную мебельную фурнитуру для скрепления деталей.
Соответственно мы получим три табуретки с совершенно разными качествами. Первая развалится через пару дней, вторая прослужит пару лет, третья будет служить долго, а при необходимости у нее можно будет легко заменить сломаную ножку.

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

Здравствуйте, Sinix, Вы писали:

S>На основе требований разрабатывается конкретные юз-кейсы — из них получаются диаграммы классов, а там уже и до архитектуры недалеко.
Это как? юзкейсы -> диаграммы классов -> архитектура

Ziaw>Это как? юзкейсы -> диаграммы классов -> архитектура
Меня даже переход юзкейсы -> диаграммы классов смущает. Потому и спрашиваю.

Ну дыкть я ж говорю — тяжко пытаться отличить маркетинг от конкретных рекомендаций Такое чувство, что я читаю не те книжки. XP/Agile — это Кент Бек и Скотт Амблерс. Кого принято читать по RUP/MSF?

Ясно, что любая методология — скорее шаблон, чем готовое решения. Посему вопрос будет звучать так: кого читать чтобы уяснить нюансы применения на практике?

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

Да, чтобы не было непонимания. Архитектура — есть функция требований. Как тогда обозвать архитектуру с точки зрения инженера? На основе чего принимаются решения?

Или этот вопрос нечто типа неуловимого джо и не входит в проблемы, которые решают методологии разработки?

Меня интересует только этот вопрос, я не хочу даже затрагивать тему о преимуществах/недостатках методологий — иначе тут же скатимся в пустой холивар.

Спасибо!

Здравствуйте, stump, Вы писали:

S>Но есть второй аспект — инженерный.
S>Допустим, есть у нас требования создать устройство для сиденя, то есть — табуретку. Табуретка штука простая, но сделать мы ее можем разными способами. Можем: а) сколотить гвоздями, б) соединить детали в шип на клею, в) использовать современную мебельную фурнитуру для скрепления деталей.
S>Соответственно мы получим три табуретки с совершенно разными качествами. Первая развалится через пару дней, вторая прослужит пару лет, третья будет служить долго, а при необходимости у нее можно будет легко заменить сломаную ножку.

Тут, видишь ли, нехилая проблема заключается в том, что 99% менеджеров, занимающихся планированием продаж и производства этих самых табуреток, совершенно наплевать на инженерные аспекты реализации табуретки. У них, как правило, основные требования — "Дешевле! Еще дешевле! Быстрее! Еще быстрее! Прямо сейчас, а еще лучше — еще вчера! Главное — продать! Быстрее!". В таких условиях, разумеется, берем абы как сделанные заготовки, и — сколачиваем их гвоздями на скорую руку.... Ну и получаем табуретку соответствующего качества.

Здравствуйте, Vlad_SP, Вы писали:


V_S>Тут, видишь ли, нехилая проблема заключается в том, что 99% менеджеров, занимающихся планированием продаж и производства этих самых табуреток, совершенно наплевать на инженерные аспекты реализации табуретки. У них, как правило, основные требования — "Дешевле! Еще дешевле! Быстрее! Еще быстрее! Прямо сейчас, а еще лучше — еще вчера! Главное — продать! Быстрее!". В таких условиях, разумеется, берем абы как сделанные заготовки, и — сколачиваем их гвоздями на скорую руку.... Ну и получаем табуретку соответствующего качества.

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

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

Здравствуйте, dmoz,

А я, знаешь-ли, совершенно согласен с тем, что эти требования диктует рынок. Но! Очень мало менеджеров, способных эти требования ранжировать в контексте всего комплекса требований к продукту, — как экономических, так и технических. Очень мало менеджеров, знающих и понимающих правило "железного треугольника". Но все же — есть.

Здравствуйте, Sinix, Вы писали:

S>Очень забавно одновременно читать введения в XP/RUP/MSF/DDD и пытаться отделить принципиальные отличия от несовпадений в терминологии.

S>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований?

Насколько я знаю, в XP последовательность следующая:

Текущие Use Case ~= текущая метафора системы -> тесты к системе -> наипростейший код, удовлетворяющий тестам

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

Вернемся к табуреткам. Заказчик хочет на чем-то сидеть.

С ним общаются и выясняют, что то на чем он сидит, должно быть достаточно переносимым с место на место и быть относительно недорогим. При этом нужно, чтобы устройство проработало год с нагрузками до 150кг. Тут возникает понимание, что нужна какая-то поверхность, на которой сидят + что-то, что держало это поверхность надо полом. При этом все достаточно легкое и прочное.

Потом пишутся тесты, которые бы проверяли, что то, что будет сделано выдержит 150,000приседаний 140кг, и что эта штука будет весить меньше 7 кг, и что объект размещенный на него будет находиться над полом на высоте 90 см.

Потом на эти тесты смотрят и говорят — а давайте сделаем все это из дерева и скрепим современной фурнитурой! Тут конечно многое зависит от программистов-плотников. Вообще подразумевается, что программисты догадаются, что тут лучший материал — дерево, и что ножки и сиденье к табуретке надо сделать как в ИКЕЕ — ножки отдельно, сиденье отдельно, чтобы если что, сделать табуретку на 6 ножках, или сиденье с круглого на квадратное заменить легко.

Здравствуйте, Sinix, Вы писали:

S>stump, если продолжить аналогию с табуреткой — как происходит выделение отдельных деталей, материалов и определение способа сборки? В требованиях этого нет, заказчику это не важно (точнее, он думает что неважно)... Зависит от квалификации разработчиков?

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

S>Да, чтобы не было непонимания. Архитектура — есть функция требований. Как тогда обозвать архитектуру с точки зрения инженера? На основе чего принимаются решения?
"Решения" — это и есть архитектура, и принимаются они на основе требований, ну и конечно квалификация "решателя" влияет сильно.

S>Или этот вопрос нечто типа неуловимого джо и не входит в проблемы, которые решают методологии разработки?
Не все. RUP, DDD рассматривают методы системного анализа, как часть своей методологии.

Здравствуйте, Sinix, Вы писали:

S>Сорри за слегка ламерский вопрос.

S>Дошли руки до изучения матчасти — книжек товарищей-гуру о конкретных методологиях.

S>Очень забавно одновременно читать введения в XP/RUP/MSF/DDD и пытаться отделить принципиальные отличия от несовпадений в терминологии.

S>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований? На основе требований разрабатывается конкретные юз-кейсы — из них получаются диаграммы классов, а там уже и до архитектуры недалеко. Не, различия есть, в UP весьма приветствуются тома экспертного анализа, а в XP — бог-заказчик. Но есть такое ощущение, что во всех приводимых примерах архитектура, разбивка на классы и т.п. проектируется исходя из требований к продукту, без учёта реализации или без учёта возможных изменений или вообще с рекомендацией забить на планирование, потому что а) фиг угадаешь и б) если будешь делать всё правильно, стоимость изменений будет линейной, расслабься

S>Конечно, я намеренно передёргиваю. Но вот Эрик Эванс (который DDD) мягенько так ругает остальных товарищей, что дескть нехорошо обижать предметную область (вообще-то он использует термин domain), она ведь самая главная и вообще давайте жить дружно и использовать одну общую концептуальную модель. И что нехорошо вообще-то строить проектпо самой нестабильной информации. Ибо требования меняются постоянно, а вот архитектура как заложена в самом начале, так и не избавишься... В то же время, сам Эрик Эванс тоже не гнушается рисовать use-case и тащить бизнес-логику в доменную модель.

S>В общем что-то тут не так. Чую, но обосновать не могу (с)Каганов.

Приведенные референсы на работы по методологиям организации труда (XP/RUP/MSF/DDD) не содержат ответа на основной вопрос, как рождается архитектура. Для этого и книжки надо по архитектуре смотреть. Давид Гарлан, Пол Клементс, Лен Басс, Рик Казман, Феликс Бахманн, Джэймс Иверс, Рид Литтле, Роберт Норд -- вот, кто пишет об архитектурах...

Use case — только лишь форма записи функциональных требований. Только по ним архитектуру не собрать никак. Нужно, как минимум, рассмотреть технические требования, и требования качества. Все вместе они подлежат анализу, в процессе которого создается концептуальная модель будущей системы, внутри которой выделяются домены, проводится ее оптимизация, и т.д. Далее, выбираются технологии, архитектурный стиль, стратегия. И уже после этого начинается работа над архитектурой как таковой. В процессе этой работы часто создают несколько прототипов системы. Подвергают их тестам, проектируя нагрузки, и т.д.

Конечно, я пытаюсь обобщить, а на самом деле, существует множество устоявшихся подходов, которые стоит изучить, если заниматься архитектурой.
Вот наиболее распространенные: 4+1, DODAF, MODAF, TOGAF, SOMF, Zachman framework.

Желаю удачи.

Здравствуйте, Nuseraro, Вы писали:

N>Текущие Use Case ~= текущая метафора системы -> тесты к системе -> наипростейший код, удовлетворяющий тестам

Там в XP user stories, которые не есть то же самое, что use cases, ибо кейсы бывают не только внешние, обусловленные функциональными требованиями, но и внутренние -- отражающие отношения между элементами архитектуры системы.
Следуя приведенной выше последовательности, xp-ры притащат плиту и стопку кирпичей общим весом 150 кг, быстро сколотят колченогое угрёбище, поставят на него плиту с кипричами, после чего приведут on-site customer-а и скажут: "вот то, что ты просил". Далее, если не будут немедленно посланы, сделают еще несколько итераций в том же духе. После чего спросят у гуру xp: "что же мы сделали не так?". На что гуру ответит: "вы не следовали всем 12-ти заветам xp bible" или что-то в этом духе.

Таак. То есть я правильно понял фишку и методологии разработки — скорее для управления проектом/получения результатов, чем для создания "идеального продукта"(тм)? Ёк...

В некоторых методологиях заниматься архитектурой неудобно как-то. В том же XP: получится идеальная, прочная монолитная табуретка из композитных материалов, вылерживающая 12,5 прямых попаданий слона. На приёмочных испытаниях заказчик, который 1000 раз описывал как выглядит табуретка, спрашивает "а где стул?". Была бы сборно-разборная табуретка — поменяли бы 2 ножки. Впрочем, поскольку мы следуем всем 12 заповедям, кардинальные изменения нас не смущают — мы создаём табуретку с дополнительными 2 ножками сверху и добавляем к ним перекладину. После чего уходим за слоном...

Попробую словами выразить то, что меня смущает: меня смущает подход "делаем один раз то, что хочет заказчик — дальше его проблемы". Как тогда быть с долгоживущим проектом, если заранее известно, что будет куча версий, что требования будут меняться и (главное!) потребуется взаимодействие с другими системами. Здесь видится отдельная проблема — мы не можем предвидеть, что от нас потребуют внешние интеграторы. Т.е. в идеале из нас должно торчать API, совпадающее с доменной моделью (говорим пока без учёта нюансов), доступ к ней должен быть через стандартные интерфейсы, да ещё и неизменным. Как к этим выводам прийти из "и эта. шоп 1с и ыксель мне работали, да!" — непознаваемо.

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

Ещё забавней проблема становится, когда мы делаем шароварный продукт и у нас нет заказчика вообще. Ясно, что продаваться мы сможем если будем быстро штамповать версию за версией с новыми мегафичами. Т.е. уже даже все разработчики заинтересованы в нормальной архитектуре. Куда им копать?

Пока из того что я прочитал, явно эти проблемы обсасывались только Эвансом — умные вещи пишет дядька. Что смущает — намёки типа "заинтересуйте всех использованием общей модели — и всё у вас получится". Утопия...

Интересно, вообще эти вопросы поднимались явно в каких-нибудь книгах?

Здравствуйте, stump, Вы писали:

S>Не все. RUP, DDD рассматривают методы системного анализа, как часть своей методологии.

Stump, а в каком месте в RUP начинает появляться системный анализ как часть проекта? Пока единственные упоминания что я видел — архитекторы должны использовать анализ, сделанный экспертами по предметной области. Вездесущий Эванс этот подход тоже критиковал, ибо теряется невербальное знание, которое нельзя передать через бумагу, аминь

Что-то подозрительно как-то у Эванса на всё ответ есть. Непризнанный пророк?

Здравствуйте, Sinix, Вы писали:

S>Интересно, вообще эти вопросы поднимались явно в каких-нибудь книгах?

Поднимались

Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, stump, Вы писали:

S>>Не все. RUP, DDD рассматривают методы системного анализа, как часть своей методологии.

S>Stump, а в каком месте в RUP начинает появляться системный анализ как часть проекта? Пока единственные упоминания что я видел — архитекторы должны использовать анализ, сделанный экспертами по предметной области. Вездесущий Эванс этот подход тоже критиковал, ибо теряется невербальное знание, которое нельзя передать через бумагу, аминь

Крэг Ларман "Применение UML и шаблонов проектирования"

Опять скажу про XP.
Здравствуйте, Sinix, Вы писали:

S>В некоторых методологиях заниматься архитектурой неудобно как-то. В том же XP: получится идеальная, прочная монолитная табуретка из композитных материалов, вылерживающая 12,5 прямых попаданий слона. На приёмочных испытаниях заказчик, который 1000 раз описывал как выглядит табуретка, спрашивает "а где стул?". Была бы сборно-разборная табуретка — поменяли бы 2 ножки. Впрочем, поскольку мы следуем всем 12 заповедям, кардинальные изменения нас не смущают — мы создаём табуретку с дополнительными 2 ножками сверху и добавляем к ним перекладину. После чего уходим за слоном...

Просто хотел бы уточнить для ясности
От монолитной табуретки должен спасать опыт программистов. XP — методология создания !ПО!, так что, если кто-то программирует не модульно, не ортогонально, не понятно то это в принципе очень плохо. И результат этого в виде монолитной табуретки, удовлетворяющей требованиям легкости, переносимости и нахождения объекта на высоте — еще очень неплохой результат. Т.е. хотя я и написал, что нужно просто написать что-то удовлетворяющее тестам и как можно проще, всё-таки имел в виду, что это не написано на санскрите через copy-paste.

От внезапной спинки должна спасать метафора системы. Так как в неё входят не только совместное понимание требований заказчика и представление о возможных реализациях этих потребностей, но и совметное понимание перспектив развития проекта, понимание какие требования строгие, а какие можно менять при обсуждении с заказчиком и т.д. Это совместное понимание не выражается в тестах, но может существенно повлиять на том этапе, где программисты по тестам пишут код. Конечно, от того случая, когда спинка была действительно неожиданной это не спасет. Это особенность XP, что оно требует, что если те люди, которые общались с заказчиком понимают, что может понадобиться спинка, то и люди которые пишут код тоже понимали, что может понадобиться спинка.

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

S>Попробую словами выразить то, что меня смущает: меня смущает подход "делаем один раз то, что хочет заказчик — дальше его проблемы". Как тогда быть с долгоживущим проектом, если заранее известно, что будет куча версий, что требования будут меняться и (главное!) потребуется взаимодействие с другими системами. Здесь видится отдельная проблема — мы не можем предвидеть, что от нас потребуют внешние интеграторы. Т.е. в идеале из нас должно торчать API, совпадающее с доменной моделью (говорим пока без учёта нюансов), доступ к ней должен быть через стандартные интерфейсы, да ещё и неизменным. Как к этим выводам прийти из "и эта. шоп 1с и ыксель мне работали, да!" — непознаваемо.

Честно говоря не совсем тут понял проблему. Выкладывают потихоньку релиз за релизом систему, она всё растёт. Все понимают, что со временем понадобится общаться с Экселем и 1Сом, а пока реализуют более важные требования. Когда наступает очередь делать интеграцию, общаются с заказчиком, предлагают свои решения, смотрят его, если он готов их предоставить, пишут по результатам общения тесты, выкладывают релизы.

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

Тут довольно ключевой момент XP. Дело в том, что это чуть ли не главная основа XP, что Software — это что-то soft, легко изменеямое. Сильно отрицается аналогия между архитектурой ПО, и архитектурой, скажем дома. Подразумевается, что ПО обладает таким свойством, что если его писать правильно, то небольшие изменения в требованиях ведут к небольшим изменениям в коде. А так релизы частые, то изменения в требованиях всегда должны быть небольшими. Ну а если заказчик приходит и говорит:"Так, все что мы писали до этого фигня", хотя видел весь процесс, то сомневаюсь, что от этого хоть что-то спасёт...

S>Ещё забавней проблема становится, когда мы делаем шароварный продукт и у нас нет заказчика вообще. Ясно, что продаваться мы сможем если будем быстро штамповать версию за версией с новыми мегафичами. Т.е. уже даже все разработчики заинтересованы в нормальной архитектуре. Куда им копать?

Это проблема масштабируемости XP. Возможны различные решения, например, "внутренний заказачик".

S>Пока из того что я прочитал, явно эти проблемы обсасывались только Эвансом — умные вещи пишет дядька. Что смущает — намёки типа "заинтересуйте всех использованием общей модели — и всё у вас получится". Утопия...

В XP вообще подразумевается, как Вы уже наверное поняли, коллективный разум. Вот это, да, утопия

Здравствуйте, Sinix, Вы писали:

S>Таак. То есть я правильно понял фишку и методологии разработки — скорее для управления проектом/получения результатов, чем для создания "идеального продукта"(тм)? Ёк...

S>В некоторых методологиях заниматься архитектурой неудобно как-то. В том же XP: получится идеальная, прочная монолитная табуретка из композитных материалов, вылерживающая 12,5 прямых попаданий слона. На приёмочных испытаниях заказчик, который 1000 раз описывал как выглядит табуретка, спрашивает "а где стул?". Была бы сборно-разборная табуретка — поменяли бы 2 ножки. Впрочем, поскольку мы следуем всем 12 заповедям, кардинальные изменения нас не смущают — мы создаём табуретку с дополнительными 2 ножками сверху и добавляем к ним перекладину. После чего уходим за слоном...

Ну, если брать конкретно XP, то переписать архитектуру не вопрос — есть же тесты, которые позволят сделать это с минимальными потерями. И заказчик там увидет каркас табуретки задолго до приемочных испытаний, так как постоянное присутствие заказчика и передача результата заказчику как можно быстрее — одни из заповедей XP. То есть после нескольких первых итераций заказчик получит предварительную версию с одной из требуемых функций. Ну скажем это будет пенопластовая табуретка выпиленная лобзиком, которая будет выдерживать игрушечного слона . Но из неё уже будет виднее, куда двигаться дальше. Заказчик сможет понять, что он действительно хотел стул, а не табуретку.
Единственное, что в жизни так не получается, заказчик хочет подробное ТЗ еще до подписания договора, требует установить сроки.. Никто ж до конца работ не будет точно знать, что ему нужно, ни заказчик, ни тем более разработчики.

S>Попробую словами выразить то, что меня смущает: меня смущает подход "делаем один раз то, что хочет заказчик — дальше его проблемы". Как тогда быть с долгоживущим проектом, если заранее известно, что будет куча версий, что требования будут меняться и (главное!) потребуется взаимодействие с другими системами. Здесь видится отдельная проблема — мы не можем предвидеть, что от нас потребуют внешние интеграторы. Т.е. в идеале из нас должно торчать API, совпадающее с доменной моделью (говорим пока без учёта нюансов), доступ к ней должен быть через стандартные интерфейсы, да ещё и неизменным. Как к этим выводам прийти из "и эта. шоп 1с и ыксель мне работали, да!" — непознаваемо.

Нет, не получится сделать "API, совпадающее с доменной моделью". Потому что доменная модель меняется постоянно. Сегодня одни бизнес-привила, завтра другие.

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

Ни один процесс не выделяет сразу ВСЕ требования в архитектуру. RUP хоть и похож на водопад, но там работы надо архитектурой начинаются до сбора всех требований. Правда, есть риск получить в самом конце одну "малюсенькую доработку", которая перечеркнет все

Быстро отвечу и исчезаю до понедельника.

Где-то выше был довод про невозможность выноса доменной модели как внешнего апи. Я правильно понимаю, что логику операций над доменом (предметной областью — кому как нравится) рассматривают как часть домена?

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

Монолитная табуретка — это идеал который можно построить из требований заказчика. Она будет удовлетворять всем требованиям — лёххкая, прочная, можно даже об ножки пивные бутылки открывать (easter egg, ага Плюс дешёвая в производстве.

Делать табуретку разборной — идти против течения, частично нарушать требования, объяснять заказчику, что он не совсем прав и т.п. Т.е. архитектурные вопросы по уму должны быть частью вопросов, которые решается в методологии. Иначе архитекторы со своими неуместными вопросами так и будут мешать "тщательно поставленному процессу" и будут типичные холивары кто главнее.

Кажется понял, откуда мой пессимизм — наследие борьбы с различными фреймворками/недоделками/неоднократное изобретание велосипедов ибо у комплектного колёса не крутились. И вот тут как раз вся логика летела на фиг, если заранее не озаботиться изоляцией от фреймворка. Поэтому подход "делаем всё с лёту и оно наверно заработает"...

Зы. Никто не имел щастья выгребать данные допустим с госовских программок типа модулей сбора и т.п. (или не дай бог обмениваться с ними инфой)? Геморрой-геморроем. Причём в основном как раз из-за тесного связывания БЛ и архитектуры. С точки зрения пользователей кстати — мегаклассные софтины, 8 лет развиваются и пользователи довольны.

Когда встречаешь в данных классификатора координаты комбобокса на форме — и без них оно не работает — уже даже рыдать не хоцца. Ещё веселее использовать API. Если оно работает по принципу "имитируем нажатие на кнопки" — уже счастье. Было весело угадывать последовательность в зависимости от введённых данных. А в следующей версии логика уже поломалась...

Про всезнающего заказчика — ещё большая утопия, чем коллективный разум Отставим пока.

stump и Локотков — спасибо за ссылки. Пока просматриваю по диагонали...

Здравствуйте, Sinix, Вы писали:

S>Быстро отвечу и исчезаю до понедельника.

S>Где-то выше был довод про невозможность выноса доменной модели как внешнего апи. Я правильно понимаю, что логику операций над доменом (предметной областью — кому как нравится) рассматривают как часть домена?

Ну, я бы рассматривал их вместе. Хотя, надо уточнять, что значит "рассматривать".

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

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

S>Монолитная табуретка — это идеал который можно построить из требований заказчика. Она будет удовлетворять всем требованиям — лёххкая, прочная, можно даже об ножки пивные бутылки открывать (easter egg, ага Плюс дешёвая в производстве.
S>Делать табуретку разборной — идти против течения, частично нарушать требования, объяснять заказчику, что он не совсем прав и т.п. Т.е. архитектурные вопросы по уму должны быть частью вопросов, которые решается в методологии. Иначе архитекторы со своими неуместными вопросами так и будут мешать "тщательно поставленному процессу" и будут типичные холивары кто главнее.

Ну тут идеал — табуретка, которая выглядит и обладает всеми свойствами монолитной, а на самом деле разборная. На эту тему есть книга "Психбольница в руках пациетов", автор Купер кажется. Потому что на деле как получается — заказчик хочет монолит, а разработчикам удобнее сделать разборную, так как заказчик каждый день хочет монолит новой формы . И в результате делается конструкция, которой удобно можно пользоваться только зная, как она устроена изнутри. Сделать же, чтобы хорошо было и тем и тем — очень нетривиально. Но я бы пользователя все-таки ставил во главе архитекторов. Хочет он эту фичу, которая по мнению архитектора абсолютно "лишняя" и не нужна — все равно надо делать. Если она действительно не нужна, время покажет. Главное, вести учет использования фич, чтобы знать, что пользователи используют, а что нет. Об этом, кстати, во второй версии XP тоже говорилось.


S>Кажется понял, откуда мой пессимизм — наследие борьбы с различными фреймворками/недоделками/неоднократное изобретание велосипедов ибо у комплектного колёса не крутились. И вот тут как раз вся логика летела на фиг, если заранее не озаботиться изоляцией от фреймворка. Поэтому подход "делаем всё с лёту и оно наверно заработает"...

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

S>Про всезнающего заказчика — ещё большая утопия, чем коллективный разум Отставим пока.

Для этого надо быть рядом с заказчиком. Но и заказчик должен быть хоть чуть-чуть грамотный. Даже у нас в не очень большой организации есть люди, которые могут внятно озвучить свою проблему и поймут, что какие-то части ПО надо переделать, чтобы им было удобнее и быстрее работать. Но есть и такие, которые упорно будут считать на бумажке, вместо того чтобы послать запрос в поддержку "а добавьте нам в отчет колонку с такими-то числами". Или ругаться на неудобную программу, но упорно продолжать с нею бороться.

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

Sshur, во многом согласен, но во это:

S>Даже если не включать туда бизнес логику — то сам набор сущностей и их атрибутов постоянно меняется.

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