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

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

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

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

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

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