Domain-Driven Design

Domain-Driven Design (DDD) — это методология, разработанная Эриком Эвансом в 2003 году, которая фокусирует архитектуру на структуре бизнес-домена, а не на технических слоях. DDD является мощным инструментом для создания сложных бизнес-приложений, где важно понимание и управление бизнес-правилами. Основные концепции DDD включают Ubiquitous Language (общий словарь разработчиков и экспертов домена), Bounded Contexts (явные границы, внутри которых термины имеют одно значение), Aggregates (границы консистентности), и Domain Events (произошедшие события). В простых CRUD-приложениях использование DDD может быть избыточным, но в сложных бизнес-доменах, где правила постоянно меняются и усложняются, DDD становится неотъемлемой частью разработки.

Как это работает

Интервью с экспертами домена помогают идентифицировать ubiquitous language, которая представляет собой общий словарь, используемый разработчиками и экспертами домена. Это позволяет всем участникам проекта говорить на одном языке и избегать двусмысленностей. Затем определяются bounded contexts — это области, где термины имеют конкретное и согласованное значение. Каждый bounded context может быть независимым и иметь свою собственную ubiquitous language.

Код проектируется таким образом, чтобы отражать структуру бизнес-домена. Имена модулей, классов и таблиц базы данных используют термины, принятые в ubiquitous language. Например, если в бизнес-процессе важен термин "Заказ", то и в коде будут использоваться соответствующие имена классов и методов, такие как Order и OrderItem.

Aggregates — это границы консистентности, которые определяют, какие операции можно выполнять над объектами без нарушения целостности данных. Например, в рамках одного заказа все операции должны быть согласованы и не должны нарушать целостность данных внутри этого агрегата.

Domain events — это события, которые описывают значимые бизнес-процессы. Они используются для отслеживания изменений в бизнес-домене и для обеспечения согласованности данных. Например, событие OrderShipped может быть использовано для обработки отправки заказа.

Когда применять

DDD особенно полезна в сложных бизнес-доменах, где бизнес-правила сложны, эволюционируют и являются центральными для ценности продукта. Примеры таких областей включают финансовую торговлю, страхование, логистику и медицину. В таких случаях DDD помогает улучшить понимание бизнес-процессов и обеспечивает согласованность между разработчиками и экспертами домена.

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

Типичные ошибки

1. DDD без доступа к domain-экспертам — для эффективного применения DDD важно иметь доступ к экспертам домена. Без общения с ними невозможно установить ubiquitous language, которая является основой DDD. Без этого DDD становится академическим упражнением, а не практическим инструментом для решения реальных проблем.
2. Over-engineering 'generic subdomain' — иногда DDD применяется к таким областям, как аутентификация или уведомления, где простой CRUD-подход был бы достаточно эффективным. Это приводит к излишней сложности и усложнению архитектуры без реальной добавленной ценности.
3. Отношение к DDD только как к архитектуре — DDD — это не только вопрос архитектуры. Это прежде всего дисциплина дизайна и коммуникации. Без ubiquitous language DDD теряет свою силу и становится бесполезным.

Связанные понятия

• Ubiquitous Language
• Bounded Contexts
• Aggregates
• Domain Events