ADR_00002: Struktura core domén – vrstvy aplikace a sdílená infrastruktura
Status: Proposed / Accepted
Date: 2025-12-28
Context
Architektura e-shopu je postavena na Domain-Driven Design (DDD) a skládá se z několika core domén (např. Checkout, Order, Stock, Pricing).
Každá z těchto domén:
- má vlastní odpovědnost a životní cyklus,
- komunikuje s ostatními doménami i externími systémy,
- musí být dlouhodobě udržitelná, testovatelná a rozšiřitelná.
Bez jednotné struktury by hrozilo:
- míchání business logiky s infrastrukturou,
- nekonzistentní implementace mezi doménami,
- obtížná údržba a refactoring,
- nejednoznačná odpovědnost vrstev.
Proto je potřeba jasně definovat vrstvy aplikace a jejich odpovědnosti.
Decision
Každá core doména bude implementována pomocí striktně oddělených vrstev:
Domain Layer
Obsahuje:
- doménové entity
- value objekty
- agregáty
- doménová pravidla
- doménové události (Domain Events)
- doménová rozhraní (např. repository interfaces)
Vlastnosti:
- nezná infrastrukturu
- neobsahuje frameworkový kód
- čistá business logika
- testovatelná bez závislostí
Application Layer
Obsahuje:
- aplikační služby (use-cases)
- orchestraci procesů
- práci s transakcemi
- publikaci doménových událostí
- volání repository rozhraní
Vlastnosti:
- neobsahuje business pravidla
- řídí tok aplikace
- propojuje doménu s infrastrukturou
- je vstupním bodem pro API / workers
Infrastructure Layer
Obsahuje:
- implementace repository
- databázový přístup
- messaging (Kafka, RabbitMQ…)
- gRPC / REST klienty
- implementaci outbox / inbox
- technické adaptéry
Vlastnosti:
- závisí na frameworku
- může se měnit bez dopadu na doménu
- je plně nahraditelná
Sdílená infrastruktura
Následující části jsou sdílené napříč doménami:
- messaging (event bus, Kafka)
- outbox / inbox mechanismus
- observability (logging, tracing, metrics)
- autentizace a autorizace
- common abstractions (base classes, helpers)
Sdílené části: - nesmí obsahovat business logiku - slouží pouze jako technická infrastruktura
Důsledky (Consequences)
Pozitiva
- Jednotná struktura napříč všemi doménami
- Vysoká čitelnost a udržitelnost kódu
- Jasná odpovědnost jednotlivých vrstev
- Podpora testovatelnosti
- Snadnější onboarding nových vývojářů
- Připravenost na microservices i modulární monolit
Negativa
- Vyšší počáteční náročnost na návrh
- Nutnost důsledně dodržovat hranice vrstev
- Více boilerplate kódu
Rationale
| Rozhodnutí | Důvod |
|---|---|
| Oddělení vrstev | Zamezuje míchání odpovědností |
| Domain bez závislostí | Umožňuje čisté testování a evoluci |
| Application jako orchestr | Přehledná logika use-cases |
| Infrastructure odděleně | Snadná výměna technologií |
| Sdílená infra | Konzistence napříč doménami |
Considered Alternatives
-
App layer jako součást prezentační vrstvy
- Pozitiva:
- Oddělení odpovědností na úrovni aplikační vrstvy (Web/ERP/Worker)
- Negativa:
- Nárůst boilerplate (Inbox/Outbox), Mediator pipelining
- Redefinice kontraktů pro repozitáře - overhead kolem implementace v případě duplicit
- Pozitiva:
-
Clean bez DDD
- Pozitiva:
- Neřeší se agregace, jsou Read-Upsert modely
- Negativa:
- Doménová logika by se dostávala do App vrstvy
- Pozitiva:
-
Infrastructure-centric approach
- Logika use-cases a orchestrací je ve vrstvě infrastruktury
- Domain layer téměř prázdná, pouze DTO/structs.
- Pozitiva:
- Rychlá implementace
- Negativa:
- Silně antiDDD