Что такое Domain-Driven Design (DDD) и в чём заключается его фундаментальная идея?

Question

DDD — это подход к проектированию, который ставит бизнес-домен в центр разработки. Главная идея — строить архитектуру так, чтобы код отражал реальные бизнес-правила и язык предметной области. Основные элементы DDD — сущности (entities), value objects, агрегаты, доменные сервисы, bounded contexts и ubiquitous language. Этот подход позволяет создавать гибкие и понятные системы, особенно когда бизнес-логика сложная.

YeaHub · Accepted Answer

Domain-Driven Design (DDD) — это философия проектирования сложных систем, предложенная Эриком Эвансом.DDD применяют, когда бизнес-логика настолько сложна, что технические паттерны сами по себе уже не справляются — нужно строить архитектуру вокруг семантики домена.Фундаментальная идея DDDРазрабатывать код так, чтобы он естественно отражал бизнес-домен, а не технические решения.Команда должна говорить на единым языком (ubiquitous language), согласованным между разработчиками и экспертами предметной области.Основные концепции DDD1. Entities (сущности)Сущности обладают уникальной идентичностью, например:ПользовательЗаказПлатёжОни живут долго и изменяют состояние.2. Value Objects (значимые объекты)Не имеют идентичности.Примеры:EmailMoneyAddressValue Object неизменяем и сравнивается по значению.3. Aggregates (агрегаты)Группы связанных сущностей и value объектов, которые изменяются атомарно.У агрегата есть корень (aggregate root).Пример агрегата → Order (корень) + OrderItem + Price.4. Domain ServicesСервисы, которые представляют бизнес-логику, не принадлежащую конкретной сущности.Например: “рассчитать стоимость доставки”.5. Bounded ContextОдна из самых важных концепций.Означает границу смыслов внутри системы.Например:контекст "Заказы"контекст "Оплаты"контекст "Каталог товаров"Каждый контекст имеет свой модельный язык и свои правила.Bounded context помогает избегать путаницы и разделять большие системы на логически независимые части.6. Ubiquitous LanguageОбщий словарь терминов, формируемый вместе с бизнесом, который затем отражается в коде.Если бизнес говорит “OrderItem”, в коде так и должно быть — а не “RowInCartTable”.Когда применять DDDDDD применяют, когда:бизнес-логика сложная;проект долгосрочный;требуется масштабируемость и гибкость;общение с заказчиком занимает важную роль;архитектура должна быть модульной.DDD не требуется в маленьких CRUD-сервисах.ВыводDDD — это способ проектировать системы вокруг бизнеса, а не вокруг технологий. Он делает сложные проекты понятнее, устойчивее к изменениям и лучше структурированными, благодаря сущностям, value объектам, агрегатам и bounded contexts.