Domain-Driven Design
Тема дорожной карты · Backend разработчик
DDD (Domain-Driven Design) — философия разработки программного обеспечения, в которой кодовая база строится вокруг богатой, явной модели бизнес-домена, что делает сложную логику более понятной, тестируемой и поддерживаемой. DDD вводит тактические строительные блоки — Сущности (объекты с идентичностью), Объекты-значения (неизменяемые дескрипторы), Агрегаты (границы согласованности), Доменные события и Репозитории — напрямую отображающие бизнес-концепции в код и сокращающие разрыв между экспертами домена и разработчиками. На стратегическом уровне DDD использует Ограниченные контексты для разбиения большой системы на автономные субдомены, каждый из которых владеет собственной схемой PostgreSQL или микросервисом, а межконтекстная коммуникация реализуется через доменные события, публикуемые в Kafka или RabbitMQ. DDD органично сочетается с CQRS и event sourcing: команды изменяют состояние Агрегата и генерируют доменные события, тогда как проекции реконструируют модели чтения в Redis или Elasticsearch для быстрых запросов. Реализация DDD в приложении на Spring Boot или NestJS обычно означает размещение всей доменной логики внутри чистых объектов домена (без аннотаций фреймворка), сохраняя инфраструктурные аспекты — HTTP-обработчики, репозитории SQLite/PostgreSQL, потребители сообщений — во внешних слоях в соответствии с Гексагональной архитектурой (Ports & Adapters).
Как это работает
Domain-Driven Design имеет варианты: монолит (один деплоябл, простой ops, тяжело масштабировать команды за ~30 инженеров), modular monolith (один деплоябл, внутренние границы модулей, масштабируется намного дальше, чем считают), микросервисы (много мелких сервисов, сложный ops, масштабирует команды). Паттерны: hexagonal / clean architecture (отделить домен от инфры), CQRS (раздельные read + write модели), event sourcing (state из event log), domain-driven design (моделируем бизнес). "Правильная" архитектура — простейшая, решающая текущие ограничения.
Когда применять
Каждый новый проект — modular monolith. Разделяйте на сервисы только когда (а) в команде > ~30 инженеров, (б) у одного компонента сильно другие требования к масштабу, (в) регуляторные границы требуют изоляции. "Архитектура" — это в основном про что вы можете дёшево менять потом; принимайте решения, откладывающие необратимость (БД на сервис — очень необратимо; границы модулей в монолите — дёшево перерисовать).
Типичные ошибки
Ловушки Domain-Driven Design: микросервисы для 5-инженерной команды (каждый сервис стоит ops + observability; больше дебажите RPC, чем шипите фичи); погоня за паттернами из FAANG-блогов на startup-масштабе (их ограничения не ваши); переписывание "ради clean architecture" без замеренной выгоды (clean ≠ better — только если окупается в изменяемости). Оптимизируйте под следующие 12 месяцев, не под 10x масштаб, которого нет.