Laravel 4.2
DDD Ultra-Light: як застосувати Domain-Driven Design без зайвих витрат
Деякі команди вважають Domain-Driven Design (DDD) складним, дорогим і таким, що потребує обережного впровадження. І справді: якщо підходити до DDD як до «великого проєкту перебудови», він може з’їсти час, бюджет і мотивацію. Але є інший шлях.
Я не працював над системою, де DDD був би «в чистому вигляді», як у підході Ерика Еванса. Проте DDD сильно вплинуло на мою професійність. Я почав використовувати окремі ідеї та принципи — ті, що можна впроваджувати поступово, без спеціальних інструментів, погоджень чи реорганізації всієї компанії. Я називаю їх DDD Ultra-Lite.
Цінність книги Еванса, на мою думку, в тому, що більшість ідей можна застосувати одразу. Вони не вимагають «правильного процесу» або складної методології. Це прості практики, які можна почати робити вже сьогодні — і отримати відчутний ефект у якості архітектури та комунікації з бізнесом.
Нижче — ключові принципи, які я взяв з DDD (у довільному порядку) і адаптував під реальні проєкти.
1) Прислухайтеся до того, що говорить бізнес
Це звучить очевидно, але в DDD Еванс формулює це дуже точно: якщо бізнес не розуміє вашу модель або вважає її неправильною — значить, над моделлю треба працювати.
Іноді бізнес не критикує напряму. Він може мовчки «тривожитися» або реагувати так, ніби щось не сходиться. Це теж сигнал: ваша модель або терміни, або логіка не потрапляють у контекст домену.
Буває і навпаки: ви нарешті знаходите адекватну модель, пояснюєте її — а у відповідь бачите здивування: «Так, ви праві… але чому вам знадобилося стільки часу, щоб це зрозуміти?» Це означає, що ви рухаєтеся в правильному напрямку.
2) Проєктуйте рівно стільки, скільки потрібно — не більше і не менше
Надмірне проєктування так само шкідливе, як і недостатнє. Баланс між глибоким мисленням і «просто реалізувати, щоб досягти мети» — складний. Еванс підказує, як тримати цей баланс.
- Використовуйте найпростішу модель, яка вирішує поточну проблему. Реальність не вдасться «спроєктувати ідеально» — її потрібно розуміти і уточнювати.
- Дбайте про чистоту коду. Архітектура має легко змінюватися. Якщо проєкт успішний, архітектуру доведеться змінювати не один раз.
- Ознака проблеми — коли зміни стають болючими. Якщо ви відчуваєте, що система «роз’їжджається», а кожна правка коштує дорого — це сигнал, що модель перестала відповідати реальності. Час на рефакторинг.
- Рефакторте маленькими кроками. Не намагайтеся переробити все одразу. Кожна нова проблема — це привід знову знайти простішу модель, яка її закриває.
- Обговорюйте. Інколи достатньо короткого мозкового штурму з розробниками або архітектором. Після цього корисно відпочити й повернутися з ясною головою.
- Не обговорюйте довше, ніж потрібно. Еванс припускає ітерації та короткі сесії (наприклад, 1–1,5 години), а також навчання через спільне обговорення.
3) Задавайте складні питання, коли архітектура «псується»
Є момент, який знайомий більшості: ви додаєте нову функцію або змінюєте існуючу — і раптом архітектура стає некрасивою. Вона ще працює, але виглядає складно, нечисто або «зламано» логічно.
У таких випадках DDD підштовхує не просто «дописати ще один if», а поставити правильні питання. Наприклад:
- Я щось упустив у концепції домену?
- Ця зміна додає або використовує концепцію, яка не підходить до поточної моделі?
Іноді відповідь означає не косметичний рефакторинг, а перегляд підходу: знайти іншу сутність, інший спосіб описати правила або навіть принципово іншу структуру.
4) Не винаходьте колесо: шукайте натхнення в інших контекстах
Еванс радить час від часу звертатися до зовнішніх джерел. Це можуть бути каталоги патернів, приклади з інших проєктів або навіть інші домени, де подібні проблеми вже вирішували.
Особисто я часто пропускав цей підхід. Зазвичай люди шукають рішення в інтернеті: блоги, презентації, форуми. Але рідко хтось каже: «Я прочитав про це в книзі XYZ і застосував». А дарма — книги часто краще структуровані й містять перевірені часом ідеї.
Мій практичний лайфхак для «дослідження проблеми»: якщо не знаєте, з чого почати, повертайтеся до теорії, переглядайте класичні джерела, фокусуйтеся на контексті та формулюванні проблеми. А ще — шукайте хороші практики від IT-професіоналів саме у вашій предметній області.
Міні-приклад: як виглядає DDD Ultra-Lite в щоденній роботі
Уявімо, що ви робите модуль «Замовлення». Після додавання нової умови (наприклад, «часткове відвантаження») код починає розростатися: з’являються додаткові прапорці, складні перевірки станів, правила розмазуються по різних місцях.
DDD Ultra-Lite підказує не лише «додати ще один if», а зробити кроки:
- Поговоріть із бізнесом: чи є в домені окреме поняття «часткового відвантаження»? Які терміни вони використовують?
- Знайдіть простішу модель для поточного сценарію: можливо, потрібна нова сутність або чіткіше правило переходів станів.
- Поставте складне питання: чи ця зміна додає концепцію, яка не вкладалася в вашу попередню модель?
- Зверніться до патернів: наприклад, до підходів зі станами (state machine) або доменних правил, описаних у класичних матеріалах.
Висновок
DDD Ultra-Lite — це не спроба «впровадити DDD назавжди». Це спосіб мислити точніше: слухати домен, проєктувати стільки, скільки потрібно, ставити правильні питання й не боятися запозичувати перевірені підходи.
Спробуйте застосувати ці принципи так, як вам підказує здоровий глузд і реальність вашого проєкту. Результат зазвичай відчувається швидше, ніж здається.
Ерік Еванс. Domain-Driven Design