ну так как правило те, кто устраивают истерику по поводу смены требований, даже не пытаются обсуждать смену чека =)

Как говорится, любой каприз за ваши деньги

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

Ну то есть «ддд не работает, если работать с мудаками», я правильно понял сообщение? Мб не надо с мудаками работать?)

Так при таких условиях любая работа страдает :)

Чисто технически  - DDD эту проблему как раз способно решить. Конкретно - его стратегическая часть. Когда у заказчика в голове находится модель разработанная совместно с программистом он способен понять экономику её изменений.
Хотя бы потому что он участвовал в её создании и у него есть понимание сколько  времени это заняло. Какие участки были наиболее сложными и какие трудозатраты требуются для их изменений.

И тут @maxlapshin  - технический отдел не должен быть сдерживающим фактором для гибкости бизнеса

@Slavenin рекоммендую добавить в https://pragprog.com/titles/jtrap/the-agile-samurai/ список на прочтение. Уверен с новыми знаниями вы приодолете постигшие вас невзгоды! 😉

интерес к DDD это уже огромный шаг вперёд

у нас программистов не допускают к разговорам с заказчиками, так что какая-там модель в чьей голове известно из третьих рук

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

если заказчик является экспертом предметной области, а я так себе это понял.

если заказчик и эксперт разные люди - значит DDD возможно если есть доступ к эксперту.
но тогда оно не поможет с вашей проблемой.
и agile не поможет

скорее-всего не поможет. уже чисто по политическим причинам

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

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

заказчик не может не понимать что нужно если он построил работающий бизнес.
а если не построил, а находится в стадии нащупывания product-market-fit (разведки боем) ему могут быть нужны прототипы, а не готовые продукты

вот тут самое интересное. а с чего ты взял что заказчик бизнесмен? или вообще его интересует прибыль?

ну он был обобщён на основе опыта работы с давно устоявшейся и глубокой предметной областью.
но это не имеет никакого отношения к меняющимся требованиям. меняющиеся к софту требования это ортогональная история

альтернативой может быть только государство, а они как раз работают по ТЗ, насколько мне известно

последние цать лет на него работаю, бардак больше, чем в коммерческой разработке, там хоть деньги считают...