DDD не починається з папки `domain`
Eric Evans представляє DDD як набір патернів і визначень для роботи з доменними моделями, а Martin Fowler підкреслює моделювання складних доменів і розвиток спільної мови між розробниками та доменними експертами. [1][2][4]
Тому структура `domain/application/infrastructure` сама по собі не робить застосунок DDD. Кодова база може мати ідеально названі папки й усе одно складатися лише з DTO та процедурної логіки. Стратегічний DDD також можна застосовувати без канонічної шарової структури.
Стратегічний DDD і тактичний DDD працюють на різних рівнях
Стратегічний DDD стосується поділу великого домену на піддомени та Bounded Contexts і визначення зв'язків між ними. Microsoft описує доменний аналіз як ідентифікацію піддоменів і обмежених контекстів, а Fowler називає Bounded Context центральним стратегічним патерном. [3][7]
Тактичний DDD працює всередині конкретного контексту та включає, зокрема, Entities, Value Objects, Aggregates і Domain Services. Microsoft явно розділяє стратегічний аналіз і тактичне моделювання. [8]
У фронтенді часто краще починати зі стратегічного дизайну і лише потім вирішувати, які контексти справді потребують багатої тактичної моделі.
Bounded Context не є технічним шаром
Fowler описує Bounded Context як межу, всередині якої модель залишається узгодженою, а терміни мають однозначне значення. Один і той самий концепт, наприклад `Customer` або `Product`, може мати різний зміст у різних контекстах. [3]
Тому `frontend`, `backend`, `React app`, `route` чи `micro-frontend` не є автоматично Bounded Contexts. Межі походять із доменної моделі та мови, а не з технології. Практичні джерела про DDD у фронтенді застерігають від тієї самої помилки. [15][16]
Коли DDD у фронтенді має сенс
| Сигнал | Напрям | Чому |
|---|---|---|
| Багато змінних бізнес-правил | DDD | Доменна модель не дає правилам розпорошуватися |
| Ті самі поняття мають різний зміст у різних частинах продукту | DDD | Bounded Contexts дозволяють підтримувати кілька узгоджених моделей |
| Співпрацюють кілька команд і доменних експертів | DDD | Ubiquitous Language зменшує неоднозначність |
| Простий CRUD і форми | Простіша модульність | Вартість тактичного DDD може перевищити користь |
| Фронтенд переважно відображає API | Простіша модульність | Мало власної клієнтської доменної логіки |
| Малий застосунок з одним узгодженим доменом | Простіша модульність | Додаткові межі та шари можуть давати мало користі |
Найсильніший сигнал це складні та часто змінювані бізнес-правила на клієнті: конфігуратори, багатокрокові процеси, pricing, права доступу, переходи станів, workflow або різні моделі одного поняття в різних частинах продукту.
DDD також корисний, коли над великим продуктом працює кілька команд і ті самі слова мають різне значення в різних областях. Bounded Contexts призначені саме для роботи з кількома узгодженими моделями. [3]
DDD Crew рекомендує спочатку зрозуміти домен, визначити стратегічно важливі піддомени, потім окреслити відповідальності Bounded Contexts і лише після цього кодувати модель. [10]
Коли DDD стає надмірною архітектурою
Якщо фронтенд переважно завантажує дані, показує їх, редагує форми та надсилає прості CRUD-команди без суттєвої бізнес-логіки на клієнті, повний набір тактичних DDD-патернів зазвичай не вирішує реальної проблеми.
Microsoft прямо зазначає, що для простого CRUD-контексту анемічної моделі даних може бути достатньо, а складніші DDD-патерни не завжди виправдовують витрати. Багата модель стає кориснішою за наявності багатьох змінних бізнес-правил. [9]
Те саме правило варто застосовувати у фронтенді: складність архітектури має відповідати складності домену, а не технічним амбіціям команди.
Ubiquitous Language має бути видно і в UI-коді
Ubiquitous Language це спільна й точна мова, яку розробники та доменні експерти будують навколо моделі. Fowler підкреслює, що вона повинна розвиватися разом із розумінням домену. [4]
У фронтенді назви use case, дій, типів, модулів, екранів і станів повинні використовувати бізнес-терміни, коли вони описують доменну поведінку.
Якщо бізнес говорить `approveApplication`, а код використовує `setFlag2` або `handleData`, код перестає бути зрозумілим відображенням доменної мови.
Великий фронтенд організовуйте за доменами, а не лише за типами файлів
Fowler зазначає, що структура верхнього рівня `view/model/data` може бути достатньою для малих систем, але зі зростанням краще мати доменно орієнтовані модулі верхнього рівня, які вже всередині містять свої шари. [5]
Актуальна документація Nx показує подібний напрям: папки можуть бути межами ownership доменів, а бібліотеки всередині домену можна класифікувати як `feature`, `ui`, `data-access` і `util`. [12]
Практична структура може виглядати як `libs/orders/...`, `libs/billing/...`, `libs/identity/...` замість одного глобального дерева `components/`, `services/`, `models/`.
Відокремлюйте презентаційну поведінку від доменної
Fowler описує поділ презентації, доменної логіки та доступу до даних як ефективну модульність. UI-код також зазвичай важче тестувати, тому винесення доменної логіки за межі презентації покращує тестованість. [5][6]
Фронтенд-компонент має переважно рендерити, обробляти UI-події та делегувати операції. Правила на кшталт можливості скасування замовлення, розрахунку знижки або допустимого переходу стану повинні мати явне місце поза JSX, шаблонами чи класами компонентів.
Це не забороняє презентаційну логіку. Валідація вигляду, видимість, локальний focus або анімація відрізняються від бізнес-правил.
Практичні шари всередині одного frontend-контексту
| Шар | Відповідальність | Приклади |
|---|---|---|
| presentation / ui | Рендеринг і поведінка інтерфейсу | components, routes, view state |
| application | Координація use case | commands, use cases, orchestration |
| domain | Доменні правила, поняття та інваріанти | entities, value objects, policies |
| infrastructure / data-access | Технічні інтеграції | HTTP, storage, SDKs, mappers |
DDD не вимагає обов'язкової структури папок. Розділення на `presentation`, `application`, `domain` та `infrastructure` є практичною інтерпретацією розподілу відповідальностей, а не формальною вимогою Evans. [1][5]
Шар domain може містити правила, поняття й поведінку, незалежні від framework; application координує use case; infrastructure адаптує HTTP, storage та зовнішні SDK; presentation містить компоненти, routing і суто UI-стан.
API-модель і доменна модель фронтенду не зобов'язані бути однаковими
Bounded Context може мати власну модель певного поняття, а різні контексти можуть мапити між різними представленнями. Fowler використовує `Customer` і `Product` як типові приклади термінів із різним значенням у різних контекстах. [3]
Тому backend DTO не зобов'язаний напряму потрапляти в кожен компонент. Mapper або adapter може перетворити транспортний контракт у модель конкретного frontend-контексту.
Така межа особливо корисна, коли API обслуговує кілька клієнтів, є legacy, поєднує кілька доменів або розвивається незалежно. Для простого CRUD endpoint додатковий mapping-шар може бути зайвим.
Entities, Value Objects і Aggregates використовуйте вибірково
DDD розрізняє, зокрема, Entities, Value Objects, Services і Aggregates. Fowler називає їх частиною словника Evans, а Microsoft описує агрегати як тактичний патерн для підтримки узгодженості моделі. [2][8]
Фронтенд не повинен копіювати backend-модель 1:1 лише заради однакових класів. Value Object корисний для `Money`, `DateRange` або `Email`, якщо він захищає реальні інваріанти. Aggregate має сенс, якщо клієнт справді повинен контролювати правила узгодженості.
Якщо тип це лише дані для рендерингу таблиці, простий TypeScript-тип може бути кращим за Entity, Factory, Repository і Service.
UI-стан і доменний стан це не одне й те саме
React розглядає організацію стану як задачу дизайну та радить уникати надлишкового чи дубльованого стану. Це корисна технічна база, але reducer, store або signals самі по собі не створюють доменну модель. [14]
Стан на кшталт `isModalOpen`, активної вкладки або позиції scroll належить презентації. Життєвий цикл замовлення, дозволені переходи процесу або правила конфігуратора можуть належати доменній моделі.
Розділення цих категорій зменшує ризик глобальних store, у яких змішані серверні дані, бізнес-поведінка та UI-деталі.
Межі потрібно примусово підтримувати, а не лише документувати
Nx дозволяє визначати project tags і декларативні dependency constraints, наприклад блокувати imports між scope або типами бібліотек. `@nx/enforce-module-boundaries` може перевіряти imports під час lint. [11]
Nx також підтримує кілька вимірів tags, тому окремо можна моделювати `scope`, тип бібліотеки, стабільність або client/server аспекти. [13]
Рішення DDD таким чином можуть стати CI-правилами: `billing` не імпортує внутрішні частини `identity`, `ui` не залежить від `data-access`, а `domain` залишається незалежним від framework.
Frontend і backend можуть ділити домен без ідентичної моделі
Bounded Context є межею моделі та мови, тому його не слід автоматично проводити по мережевій межі між браузером і сервером. Практичні матеріали про DDD у фронтенді підкреслюють, що контексти можуть перетинати технічні шари й реалізовуватися спільно фронтендом і бекендом. [15][16]
Клієнтське представлення водночас може відрізнятися від серверного через інші потреби взаємодії, локального стану та презентації. Важливо зберігати семантику й явно мапити, а не копіювати класи.
Micro-frontend також не повинен з'являтися лише тому, що існує Bounded Context. Доменна межа та межа deployable-артефакту це різні рішення.
Тестованість є сильним аргументом за ізоляцію доменної логіки
Fowler називає тестованість перевагою відокремлення презентації від домену. Логіку поза UI можна тестувати без рендерингу компонентів і без залежності від деталей інтерфейсу. [5][6]
У фронтенді це дозволяє швидко тестувати правила, Value Objects, use case і переходи станів як звичайний TypeScript або JavaScript. Тести компонентів залишаються потрібними, але не повинні бути єдиним місцем перевірки бізнес-правил.
Тривожний сигнал це ситуація, коли кожна зміна бізнес-правила вимагає mount повного компонента та mock router, store, HTTP і browser API.
Як запровадити DDD в існуючий фронтенд без великого rewrite
DDD Crew рекомендує ітеративний процес: зрозуміти домен, визначити важливі піддомени, окреслити відповідальності Bounded Contexts і лише потім кодувати модель. [10]
В існуючому фронтенді безпечніше вибрати одну проблемну бізнес-область, назвати її мову, встановити межу, відокремити презентацію від правил, визначити публічний API модуля і лише потім переносити інші функції.
Не потрібно мігрувати весь застосунок. DDD можна застосовувати там, де бізнес-складність окупає моделювання, а прості області залишити легкими feature modules.
- Починайте з бізнес-проблеми, а не з папок.
- Визначте терміни, правила та неоднозначні поняття.
- Окресліть один Bounded Context і його публічний контракт.
- Відокремте доменні правила від компонентів і транспортних DTO.
- Додавайте лише тактичні патерни, які вирішують конкретну складність.
- Закріпіть межі як lint або CI-правила.
- Вимірюйте залежності, цикли, регресії та вартість наскрізних змін.
- Не мігруйте прості CRUD-області лише заради архітектурної симетрії.
