Недавно писал статью на Хабре про проектирование, с использованием DDD подхода, вот она.

Кратко о DDD
Это комплекс подходов к проектированию, не имеющий ярко выраженного конца, за все хорошее, против всего плохого.

Статья вызвала холивар и заставила меня переосмыслить саму суть DDD.

Я решил сделать условное разделение ролей пользователей этого подхода на заказчиков и разработчиков.

* Разработчики - с упрощённой точки зрения, это команда, которая находится с другой стороны от линии, которая разделяет заказчиков фичи от реализованной фичи на проде.
Для упрощения, я осознанно скипаю СА, QA, ПО, ДМ и другие роли.

* Заказчики - Это команда, которая находится с другой стороны, относительно разработчиков, заказчик хочет фичи на проде максимально быстро. С учетом всех танцев в интерпрайзе, пока задача доходит до прода, сроки уже горят.

Идеальные условия, когда бизнес просит научить разработчиков писать код, соблюдая DDD, но сможет ли бизнес отказаться от своих естественных привычек доставки фичей АСАПом? Ведь DDD - это долгий процесс проектирования, где сегодняшние договорённости могут измениться завтра из-за новых вводных. Это ведёт к бесконечным обсуждениям и сдвигам сроков, что является ред флагом для бизнеса.

Аллегории, интересные факты:

* Бурдж-Халифа. Её построили быстро, но не подключили к городской канализации. Бизнес получил магнит для туристов и деньги, хоть и с временным решением (вывоз нечистот машинами). Полное проектирование «по уму» отложили.

* OpenAI. Это MVP, который быстро взлетел и зарабатывает.  Кодовая база - огромный монорепозиторий без единых стандартов. Решения принимали те, кто писал код, а не архитекторы. Результат - полдюжины разных библиотек для одних и тех же задач. CI падал регулярно, тесты грузились по 30 минут. Но бизнес не ждал идеальной архитектуры. Будь там DDD, продукта могло бы и не быть.
Источник.

И я пришел к следующим выводам:

* Основной вывод: Бизнес снова доказал, иногда сделать и вывезти нечистоты машинами выгоднее, чем годами проектировать идеальную канализацию.

* Второстепенный вывод:  Учить разработчиков DDD в условиях, где бизнес не готов давать время на проектирование - всё равно что отправлять повара из столовой на курсы Мишлен, чтобы он потом снова готовил кашу из топора. Знания будут не применимы.

В чём тогда смысл DDD для бизнеса, который не может ждать?

Насколько сильно нужен DDD интерпрайзу? Да и вобще кому-то?