Вопрос проверяет понимание концепции DDD, её терминологии и того, какую роль она играет в построении сложных бизнес-систем.
DDD — это подход к проектированию, который ставит бизнес-домен в центр разработки. Главная идея — строить архитектуру так, чтобы код отражал реальные бизнес-правила и язык предметной области. Основные элементы DDD — сущности (entities), value objects, агрегаты, доменные сервисы, bounded contexts и ubiquitous language. Этот подход позволяет создавать гибкие и понятные системы, особенно когда бизнес-логика сложная.
Domain-Driven Design (DDD) — это философия проектирования сложных систем, предложенная Эриком Эвансом.
DDD применяют, когда бизнес-логика настолько сложна, что технические паттерны сами по себе уже не справляются — нужно строить архитектуру вокруг семантики домена.
Разрабатывать код так, чтобы он естественно отражал бизнес-домен, а не технические решения.
Команда должна говорить на единым языком (ubiquitous language), согласованным между разработчиками и экспертами предметной области.
Сущности обладают уникальной идентичностью, например:
Пользователь
Заказ
Платёж
Они живут долго и изменяют состояние.
Не имеют идентичности.
Примеры:
Money
Address
Value Object неизменяем и сравнивается по значению.
Группы связанных сущностей и value объектов, которые изменяются атомарно.
У агрегата есть корень (aggregate root).
Пример агрегата → Order (корень) + OrderItem + Price.
Сервисы, которые представляют бизнес-логику, не принадлежащую конкретной сущности.
Например: “рассчитать стоимость доставки”.
Одна из самых важных концепций.
Означает границу смыслов внутри системы.
Например:
контекст "Заказы"
контекст "Оплаты"
контекст "Каталог товаров"
Каждый контекст имеет свой модельный язык и свои правила.
Bounded context помогает избегать путаницы и разделять большие системы на логически независимые части.
Общий словарь терминов, формируемый вместе с бизнесом, который затем отражается в коде.
Если бизнес говорит “OrderItem”, в коде так и должно быть — а не “RowInCartTable”.
DDD применяют, когда:
бизнес-логика сложная;
проект долгосрочный;
требуется масштабируемость и гибкость;
общение с заказчиком занимает важную роль;
архитектура должна быть модульной.
DDD не требуется в маленьких CRUD-сервисах.
DDD — это способ проектировать системы вокруг бизнеса, а не вокруг технологий. Он делает сложные проекты понятнее, устойчивее к изменениям и лучше структурированными, благодаря сущностям, value объектам, агрегатам и bounded contexts.
