DDD часто сприймають як набір тактичних патернів: репозиторії, фабрики, агрегати, value objects, шари. Перенесені механічно в Laravel-проєкт, вони дають багато коду й мало користі. Прагматичний підхід - брати ідеї, а не церемонії.
Що варто брати майже завжди:
- єдина мова: назви моделей, методів, подій і енумів - зі словника бізнесу (
$order->cancel(),OrderCancelled,OrderStatus::Refunded); - поведінка поруч з даними для важливих правил: методи на моделях замість
$order->status = ...по всьому коду; - енуми й об'єкти-значення для грошей, статусів, періодів - через касти Eloquent;
- доменні події для побічних ефектів;
- actions/use cases - один клас на бізнес-операцію (
PlaceOrder,RefundPayment): зрозуміла точка входу, легко тестувати; - модулі за предметними областями, а не за технічними шарами, коли проєкт росте:
app/Domain/Billing/{Models,Actions,Events,Enums}
app/Domain/Catalog/...
app/Domain/Shipping/...
Що варто брати лише для складного ядра:
- агрегати з явними межами і заборона змінювати дочірні сутності напряму;
- окремі моделі читання (CQRS) для важких звітів і списків;
- антикорупційні шари навколо зовнішніх інтеграцій.
Що зазвичай зайве в Laravel-проєкті:
- репозиторії-обгортки над Eloquent «для чистоти» - дублюють Eloquent і не дають ізоляції;
- окремі доменні класи + мапінг у Eloquent для простих сутностей - десятки класів перетворень;
- повна гексагональна архітектура для CRUD-адмінки;
- event sourcing без бізнес-потреби в історії.
Як вирішувати, де межа: спершу визначити основний піддомен (те, що приносить гроші й має складні правила). Там - більше моделювання й захисту інваріантів. Допоміжні й загальні частини - звичайний Laravel: моделі, Form Request, ресурси, Filament.
Ознаки, що складність виправдана:
- бізнес-правила часто змінюються і їх багато;
- помилки дорогі (гроші, юридичні наслідки);
- над кодом працює кілька команд.
Ознаки «DDD заради DDD»: більше коду інфраструктури, ніж бізнес-логіки; кожна проста зміна торкається п'яти шарів; нові розробники тижнями не розуміють, куди писати код.
Підсумок для співбесіди: DDD - насамперед про розуміння предметної області й спільну мову з бізнесом. Тактичні патерни - інструменти, які вмикають там, де складність домену цього вимагає.
Докладніше в документації: Martin Fowler: Domain Driven Design