DDD — обзор
Domain-Driven Design — подход, в котором во главе стоит доменная область (предметная). Не рецепт, а идея — разные команды реализуют DDD по-своему.
Что это / Зачем
- Центр приложения — доменная модель, а не БД/UI/фреймворк.
- Минимальная идея DDD: разделить приложение на слои (домен, application, инфраструктура).
- Расширенная: агрегаты, проекции, value objects, репозитории, use cases, bounded contexts.
Слои в DDD
┌──────────────────────────────────┐
│ Presentation (UI/API) │
├──────────────────────────────────┤
│ Application (use cases) │
├──────────────────────────────────┤
│ Domain (бизнес-логика, модели) │ ← ядро, никуда не зависит
├──────────────────────────────────┤
│ Infrastructure (БД, HTTP, fs) │
└──────────────────────────────────┘
Failed Promises of DDD
DDD — не догма. Серия статей «Failed Promises of DDD» — про то, что не нужно слепо следовать рецептам, нужно брать саму идею: организация бизнес-логики на домене.
Антипаттерн: натягивание DDD на CRUD
// слепое следование DDD на простой CRUD-app:
// 5 классов Repository + Factory + Specification + ValueObject + DomainEvent
// для сохранения формы из 3 полей — overengineering.
🎓 Источники
- 🎓 [Q&A Patterns Call #13 — литература, DDD, моделирование] · 2025-01-01 · YouTube
- «DDD ставит домен в центр. Одно DDD не равняется другому DDD».
- Failed Promises of DDD — DDD как идея, не рецепт.
- 🎓 [Почему на фронтенде не выходит DDD и Clean architecture] · 2025-02-23 · YouTube
- Альтернативная позиция: DDD на фронте плохо приживается, потому что во фронте всё мечется между фреймворками. DDD не сводится к доменной логике — это ещё агрегаты, проекции, разные интерфейсы одной сущности в разных контекстах.
- 🎓 [Metarhia Weekly #192 — DDD фронт + бэк] · 2025-03-01 · YouTube
- В DDD база — это инфраструктура, от неё нужно абстрагироваться.