Запропонувати правкуПокращити цю статтюДопрацюйте відповідь до «Що таке Domain-Driven Design (DDD)?». Ваші зміни проходять модерацію перед публікацією.Потрібне підтвердженняКонтентЩо ви змінюєте🇺🇸EN🇺🇦UAПереглядЗаголовок (UA)Коротка відповідь (UA)**Domain-Driven Design (DDD)** - підхід до проєктування програмних систем, у якому все будується навколо бізнес-домену (предметної області) - тобто навколо реального сенсу і логіки бізнесу, а не технологій, фреймворків чи баз даних. **Ключове:** модель коду повинна бути дзеркалом бізнес-мислення - не просто зберігати дані, а мислити так само, як бізнес.Показується над повною відповіддю для швидкого нагадування.Відповідь (UA)Зображення**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. **Приклад (інтуїтивно):** Замість: ```python def create_order(user_id, items): db.insert("orders", user_id, items) ``` DDD змусить запитати: - Що означає «створити замовлення» з погляду бізнесу? - Чи можна створювати замовлення без оплати? - Що відбувається, якщо товарів немає на складі? Тоді в коді з'являться доменні класи: ```python 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** > Модель коду повинна бути **дзеркалом бізнес-мислення**. > Не просто зберігати дані, а **мислити так само, як бізнес**.Для рев’юераПримітка для модератора (необов’язково)Бачить лише модератор. Прискорює рев’ю.