Domain-Driven Design (DDD): От хаоса к четкой модели системы

Domain-Driven Design (Проектирование, управляемое предметной областью) — это не просто набор паттернов программирования, а философия разработки, направленная на решение проблем в сложных бизнес-системах. Основная идея: программный код должен максимально точно отражать бизнес-логику и говорить на языке экспертов.

1. Фундамент: Домен и Проблема понимания

В основе DDD лежит Домен (Предметная область) — сфера деятельности, в которой работает бизнес (например, банковское дело, логистика или заказ технических интервью).

Главная проблема в разработке — Полисемия (многозначность). Одно и то же слово может иметь разные значения в разных отделах.

Пример: Слово «PIN» для разработчика мобильных ОС — это код разблокировки экрана, а для сотрудника банка — это код подтверждения транзакции по карте.

Чтобы избежать путаницы, в DDD вводятся два ключевых понятия:

Ubiquitous Language (Единый язык) — терминология, которую одинаково понимают и разработчики, и бизнес-эксперты. Если эксперт говорит «Заказ», в коде должен быть класс Order, а не Deal или Transaction.
Bounded Context (Ограниченный контекст) — логическая граница, внутри которой модель и язык остаются неизменными. В контексте «Профиля пользователя» объект User содержит почту и пароль, а в контексте «Доставки» тот же User — это лишь адрес и номер телефона.

2. Кирпичи домена: Внутренняя архитектура

Когда границы очерчены, мы начинаем строить систему из трех основных типов объектов:

Entity (Сущность)

Это объект, который обладает уникальной идентичностью (ID). Обладает следующими свойствами:

Identifier equality: Сравнивается только по ID. Даже если все поля объекта изменились, это всё та же сущность, пока ID прежний.
Жизненный цикл: Сущность проходит через разные состояния (например, заказ: Создан → Оплачен → Доставлен).
Защита границ: Сущность сама следит за соблюдением бизнес-правил (инвариантов). Например, нельзя сменить дату доставки заказа, если он уже доставлен.

Value Object (Объект-значение)

Объект, у которого нет ID, он описывает характеристики чего-либо. Обладает следующими свойствами:

Structural equality: Сравнивается по значениям всех полей. Два объекта «100 Рублей» абсолютно идентичны.
Неизменяемость (Immutability): Мы не меняем значение внутри объекта. Если нужно изменить цену, мы создаем новый экземпляр Price с новым значением.
Заменяемость: Их легко выбрасывать и заменять на новые.

Aggregate (Агрегат)

Это кластер взаимосвязанных объектов (сущностей и объектов-значений), которые рассматриваются как единое целое. Обладает следующими свойствами:

Aggregate Root (Корень агрегата): Единственная входная точка. Внешний мир может обращаться только к корню (например, к Order), а корень сам управляет внутренними объектами (например, позициями в заказе OrderItem).
Консистентность: Агрегат гарантирует, что все данные внутри него согласованы в любой момент времени.

3. Доменные примитивы и борьба с «одержимостью»

Частая ошибка — использование стандартных типов (string, int) для бизнес-понятий. Это называется Primitive Obsession (Примитивная одержимость).

Доменный примитив (разновидность Value Object) решает эту проблему:

Валидация при создании: Нельзя создать объект Email, если строка не содержит «@». Объект просто не родится в невалидном состоянии.
Чистота кода: Вместо того чтобы везде проверять длину строки или формат телефона, вы один раз инкапсулируете эту логику внутри доменного примитива.

Резюме: В чем сила DDD?

Сила подхода в том, что он делает невозможным нарушение фундаментальных бизнес-правил. Если ваша модель спроектирована верно:

Вы не сможете создать заказ без клиента.
Вы не сможете установить отрицательную цену.
Разработчики и бизнес будут говорить на одном языке, что сократит количество багов из-за недопонимания.