это несколько другой вопрос.
DDD подразумевает что ты, как разработчик, не знаешь предметной области. Более того - сам бизнес часто не знает как у него все работает. Скажем у тебя есть несколько департментов бизнеса и "на границах" часто есть проблемы которые не видны. Вещи которые снижают эффективность.
Как "раньше" было - есть скажем бизнес аналитик. Он 3+ месяцев вкуривает в предметную область, разбирается "че зачем и почему". Составляет спецификацию, описывает юзкейсы и вот это все. Имея доступ к разработчикам может придумывать решения. Такая вот прослойка для формализации требований. И не нужны никакие эти ваши DDD.
Что изменилось за последние 20-30 лет - это степень интеграции IT в бизнес. Если раньше речь шла о прямом переносе бизнес процессов то сегодня IT системы сильно влияют и трансформируют бизнес сам по себе. Изменился характер взаимодействия с клиентами бизнеса. Изменились требования к скорости поставки - все очевидное сделано - нужно экспериментировать - нужно сокращать риски для экспериментов.
Раньше у тебя небыло выбора и ты покупал мэйнфрейм, сегодня ты можешь в клаудах деплоиться и за счет этого существенно сокращать расходы на operations. Раньше "можно было раз в месяц патчить сервера и все было ок", сегодня слишком много вещей которые отъедают времени и сил и потому появляются решения типа serverless и прочие идеи platform as a service.
Все популярные нынче подходы и идеи (не только DDD) в какой-то степени эксплуатируют идею мол для эффективного принятия решения нужно более тесное взаимодействие разных экспертиз. Далее вопрос для каких областей это нужно а для каких "лучше спецификацию накидать и скинуть в аутсорс и где лучше готовый софт купить". Проблема в том что большинство все еще на стадии когда "лучше бизнес аналитика наймите толкового". Это все имеет смысл обсуждать когда у вас lead time не меряется годами.
