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

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

O>>Тут проблема , в том что заказчик или его представители как правило занимается своим бизнесом и у него нет времени объяснять долго, порой даже не продумывая как это все должно работать, а это необходимо если проект не на 1 день, а большой. Т.е. этот этап идеален но не очень практичен например на больших проектах размером в 1 чел.год .

S>Baudolino уже всё неаписал, дополню: DDD работает, если вся команда готова разобраться в предметной области хотя бы настолько, чтобы хотя бы понимать, о чём говорит заказчик.
S>Если начинаются отмазки в духе "некогда думать, программисты простаивают", "разбираться — это работа аналитика, а не программиста" и тыды — DDD можно выбрасывать. И, за редким исключением, сам проект тоже.

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