Domain Driven Design — предметно-ориентированное проектирование

DDD учит нас (разработчиков) разговаривать с бизнесом на одном языке. Это называется в DDD Единый язык (Ubiquitous language).

Ограниченный Контекст (Bounded Context) — ключевой инструмент DDD, это явная граница, внутри которой существует модель предметной области.

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

Для тимлидов такой подход позволяет в значительной степени распараллелить работу команд(ы), что может значительно ускорить работу по проекту.

Кроме ограниченного контекста есть ещё всякие штуки типа карт контекстов, единого языка, отношений между контекстами, карты трансляций

DDD — довольно старый подход. Его использование выглядит разумным и вполне оправданным, но почему-то он всё ещё мало распространён, про него мало говорят на конференциях.

RGB книги

Как понять, что пора применять DDD

это нужно не всем

Посчитайте количество сценариев использования вашей системы. Если их в районе 10-15, значит бизнес-логика не такая сложная, и вы можете не париться, никакого DDD не применять.

Если у вас 30-50 и более UX-кейсов, и они очень сильно пересекаются, имеет смысл задуматься над применением DDD хотя бы в какой-то части системы.

Как внедрить DDD в компании снизу вверх

парадигме «Разделяйте, делите, понижайте связность и следите за бизнес-логикой»

Умею DDD — неважная строчка для резюме в России

Если вы находитесь в России и знаете DDD — это круто

Связь DDD с волосами на лице

Наблюдение: люди, которые разбираются в DDD, носят бороды. Значит ли это, что наличие бороды — предпосылка к успешности в DDD?