Що таке Domain-Driven Design (DDD)?
Domain-Driven Design (DDD) - це підхід до проєктування програмних систем, у якому все будується навколо бізнес-домену (предметної області) - тобто навколо реального сенсу і логіки, а не технологій, фреймворків чи баз даних.
Головна ідея DDD:
Код повинен відображати реальність бізнесу, а не структуру таблиць чи особливості фреймворка.
1. Що таке "домен"
Домен - це область знань, у якій працює система. Наприклад:
- для банку - це кредити, рахунки, перекази;
- для інтернет-магазину - товари, замовлення, кошик;
- для CRM - клієнти, угоди, комунікації.
DDD каже:
спершу розберися, як живе цей світ, і лише потім пиши код.
2. Ключова мета
Створити модель, яка:
- відображає реальні бізнес-правила,
- зрозуміла і розробникам, і експертам домену,
- ізольована від інфраструктури.
3. Основні поняття DDD
| Концепт | Що це |
|---|---|
| Ubiquitous Language (вездесуща мова) | Спільний словник термінів між програмістами та бізнесом. Один термін - одне значення в коді та в мовленні. |
| Entity (Сутність) | Об'єкт, що має ідентичність і життєвий цикл. Приклад: Користувач, Замовлення. |
| Value Object (Об'єкт-значення) | Об'єкт без ідентичності, важливі лише його властивості. Приклад: Гроші (валюта + сума). |
| Aggregate (Агрегат) | Група пов'язаних сутностей і об'єктів-значень, об'єднаних логікою. Приклад: Замовлення та його позиції. |
| Aggregate Root (Корінь агрегата) | Головна сутність, через яку керують усім агрегатом. |
| Repository (Репозиторій) | Інтерфейс для отримання і збереження агрегатів (робота з БД абстрагована). |
| Service (Сервіс домену) | Дія, яка не належить конкретній сутності, але важлива для домену. |
| Domain Event (Подія домену) | Подія, яка сталася в бізнес-логіці і може викликати реакції в інших частинах системи. |
4. DDD і архітектура
DDD чудово поєднується з Clean Architecture. Clean Architecture - про структуру і залежності, а DDD - про сенс і мову, яка живе всередині цих шарів.
Зазвичай домен (entities, aggregates, value objects, domain services) розташовується в центрі чистої архітектури.
5. Приклад (інтуїтивно):
Замість:
def create_order(user_id, items):
db.insert("orders", user_id, items)DDD змусить запитати:
- Що означає «створити замовлення» з погляду бізнесу?
- Чи можна створювати замовлення без оплати?
- Що відбувається, якщо товарів немає на складі?
Тоді в коді з'являться доменні класи:
class Order:
def add_item(self, product, quantity):
if not product.in_stock(quantity):
raise OutOfStockError()
self.items.append(OrderItem(product, quantity))Тепер логіка описує реальний бізнес-сенс, а не SQL-запис.
6. Головний принцип DDD
Модель коду повинна бути дзеркалом бізнес-мислення. Не просто зберігати дані, а мислити так само, як бізнес.
Коротка відповідь
Для співбесідиКоротка відповідь допоможе вам впевнено відповідати на цю тему під час співбесіди.