🟠 Domain-Driven Design (DDD): что это и зачем, разбор с примерами 🟠

При работе с крупными системами на этапе проектирования легко утонуть в сотнях бизнес-требований, бизнес-правил и интеграций.

В таких ситуациях на помощь приходит Domain-Driven Design (DDD).

📌 DDD — подход, при котором мы проектируем систему, отталкиваясь от предметной области и понимания языка бизнеса, а не от технических деталей и функциональных требований.


Ключевое:

✅ Единый язык (Ubiquitous Language)
Договариваемся, что бизнес и разработчики используют одинаковые слова, и понимают их одинаково.

Например, в системе парковок:
“Сессия” = время от въезда до выезда
“Льготный клиент” = владелец абонемента или спец. допуска

Результат — меньше путаницы в ТЗ, коде и общении.


✅ Ограниченные контексты (Bounded Context)
Делим большую систему на зоны, внутри которых термины и правила работают одинаково, а за их пределами — могут отличаться.

В системе для парковок мы понимаем, что у нас могут быть большие части:

+ Контроль доступа (камеры, шлагбаумы, проверка разрешений)
+ Платежи (расчёт тарифа, оплата, возвраты)
+ Учёт мест (свободно/занято, бронирования)

Внутри каждой части свои правила и детали, которые не мешают остальным.


💡 Важный момент:
Один Bounded Context ≠ всегда один микросервис.

Это логическая граница. Внутри неё может быть один сервис, несколько микросервисов или модуль монолита.

Но при переходе к MSA часто делают так, что каждый контекст превращается в один или несколько микросервисов.



✅ Модель предметной области (Domain Model)

Это карта всех объектов системы и их правил — в коде, БД, API.

Для системы парковки это может быть:

+ Сущности:
++ ParkingSession: начало, конец, тариф, сумма, статус оплаты.
++ Vehicle: номер, тип, льготы.
++ Spot: зона, номер, статус.

+ Правила:
++ без оплаты выезд запрещён, кроме льготных клиентов;
++ место освобождается только после закрытия сессии парковки.



👉 DDD помогает навести порядок в сложном проекте:

+ общий словарь → меньше недопонимания

+ границы контекстов → управляемая архитектура (и потенциальная основа для микросервисов)

+ модель предметной области → понятный “скелет” системы

Кроме того, что мы наводим порядок, очень часто удаётся закрыть множество пробелов в требованиях при таком подходе.


Если начать проект с этих трёх шагов, то даже самая запутанная система будет спроектирована логично и её развитие будет (без) с меньшим количеством сюрпризов.


#АрхитектураGA #ParkingGA