Глава 13. Предметно-Орієнтоване Проектування на Практиці

Теорія DDD звучить чудово. В ідеальному світі ми починаємо нові проекти (Greenfield), формуємо ідеальну команду, де кожен експерт володіє термінологією DDD, і створюємо бездоганну модель.

Але реальність, з якою ми стикаємося щодня, виглядає інакше:

• Ми працюємо з Brownfield проектами (існуючий код, написаний 5-10 років тому).
• У нас є Big Ball of Mud (Великий Комок Бруду).
• Бізнес вимагає нових фіч "на вчора", а не рефакторингу.
• Команда не знає (і часто не хоче знати) про Агрегати та ВО.

У цій главі ми поговоримо про те, як застосовувати DDD в реальних, недосконалих умов. Як бути прагматичним, а не догматичним.

1. Стратегічний Аналіз Legacy

Перш ніж кидатися переписувати код, потрібно зрозуміти ландшафт. Згадайте стратегічні патерни з Частини I. Вони тут навіть важливіші, ніж у новому проекті.

Оцінка Ландшафту

Запустіть процес Knowledge Crunching (наприклад, EventStorming з Глави 12), щоб відновити втрачені знання про систему. Вам потрібно відповісти на питання:

1. Де гроші? Який піддомен є Core Domain?
2. Де біль? Який модуль має найбільше багів і найвищу складність змін?
3. Яка структура? Які є високорівневі компоненти і як вони пов'язані?

Класифікація Піддоменів

Не намагайтеся рятувати все.

• Generic / Supporting Subdomains: Якщо тут "бардак", але воно працює і рідко змінюється — не чіпайте. Витрачати ресурси на рефакторинг адмінки, яка працює — це марнотратство.
• Core Domain: Це ваш пріоритет. Тут "бардак" коштує бізнесу грошей (повільні зміни, баги в розрахунках). Саме тут варто впроваджувати DDD.

2. Стратегії Модернізації

"Переписати з нуля" (Big Rewrite) — це майже гарантований провал. Замість революції, обирайте еволюцію.

Патерн Strangler Fig (Фікус-Душитель)

Цей патерн названо на честь рослини, яка росте на дереві-хазяїні, поступово обвиває його і з часом замінює, залишаючи дерево вмирати всередині.

User --> Traffic
Traffic -->|Old Features| Legacy
Traffic -->|New Features| New
Traffic -->|Migrated Features| New

style Legacy fill:#e0e0e0,stroke:#9e9e9e
style New fill:#c8e6c9,stroke:#4caf50

Алгоритм:

1. Створіть новий модуль/сервіс поруч зі старим.
2. Реалізуйте нову функціональність в новому модулі.
3. Налаштуйте фасад (API Gateway або Load Balancer) для перенаправлення трафіку.
4. Поступово переносьте існуючу функціональність зі старого в новий.
5. Коли старий модуль спорожніє — видаліть його.

Bubble Context (Контекст-Бульбашка)

Якщо ви не можете виділити окремий сервіс, створіть "чисту зону" всередині моноліту. Це ваш новий Bounded Context.

Tactical Forking (Тактичне Розгалуження)

Іноді розплутувати залежності ("клубок спагетті") занадто дорого. Якщо вам треба розділити моноліт на два (наприклад, "Продажі" і "Логістика"), і код сильно зв'язаний:

1. Зробіть копію всього проекту (Copy-Paste).
2. В одній копії ("Продажі") видаліть все, що стосується Логістики.
3. В іншій копії ("Логістика") видаліть все, що стосується Продажів. Це брудно, але це працює, коли розчепити залежності на рівні класів неможливо.

3. Тактичний Рефакторинг

Як перейти від Transaction Script (процедурний код) до Domain Model (ООП)? Робимо це крок за кроком.

4. Як "продати" DDD бізнесу?

Якщо ви прийдете до менеджера і скажете: "Нам треба переписати систему на Агрегати, бо це правильно", вас виженуть. Бізнес не купує патерни. Бізнес купує вирішення проблем.

Аргументи для бізнесу

1. Зменшення кількості помилок (Bugs): "Минулого місяця ми 3 рази фіксили розрахунок знижки. Якщо ми виділимо це в окремий модуль з чіткими правилами, це не повториться".
2. Time-to-Market: "Зараз додавання нової кнопки займає тиждень, бо ми боїмося зламати старе. З ізольованими контекстами ми зможемо деплоїти це за день".
3. Onboarding: "Новим розробникам потрібно 3 місяці, щоб зрозуміти цей код. Якщо ми введемо "Єдину Мову" (Ubiquitous Language), вони зрозуміють бізнес за 2 тижні".

Партизанське DDD (Covert DDD)

Іноді краще взагалі не використовувати терміни DDD. Не кажіть "Bounded Context". Кажіть "Модуль" або "Продукт". Не кажіть "Ubiquitous Language". Кажіть "Словник термінів". Просто робіть це. Використовуйте правильні імена в коді. Будуйте чисті моделі. Ваша робота — писати якісний код, і вам не завжди потрібен дозвіл на використання правильних інструментів.

5. Висновок

DDD — це не срібна куля. Це набір інструментів для боротьби зі складністю.

• Використовуйте Стратегічне DDD (Context Maps, Subdomains), щоб зрозуміти що ви будуєте. Це корисно завжди, в будь-якому проекті.
• Використовуйте Тактичне DDD (Aggregates, Value Objects) тільки там, де це виправдано складністю (Core Domain).

Ніколи не застосовуйте DDD тільки заради того, щоб поставити галочку в резюме. Головна мета — створити програмне забезпечення, яке приносить цінність і яке можна підтримувати роками.

Вправи

1. Ви працюєте над Legacy-системою електронної комерції. Модуль "Знижки" реалізований як набір SQL-процедур на 2000 рядків. Він постійно ламається. Яку стратегію модернізації ви оберете?
   • Bubble Context?
   • Strangler Fig?
   • Rewrite from scratch?
2. Ваш менеджер каже: "Ми не маємо часу на EventStorming, просто почніть кодити". Яка ваша відповідь? (Виберіть найбільш прагматичну).
3. Чому тактичне розгалуження (Tactical Forking) називають "брудним" методом і коли воно виправдане?

Кінець. Дякуємо, що були з нами у цій подорожі світом Domain-Driven Design!