Jan Mikoláš
Vrstvená aplikace
Kde patří odpovědnost a transakce
- UI: HTTP, Console nebo message handler
- Application: use case a transakční hranice
- Domain: pravidla, entity a value objects
- Infrastructure: databáze, fronta a framework
Zpět na znalosti
Způsob práce
Architektura aplikací
Architekturu nevolím podle názvu vzoru, ale podle složitosti problému. Cílem jsou čitelné hranice, bezpečné změny a řešení přiměřené velikosti aplikace.
Struktura má pomáhat změnám, ne je komplikovat.
U větších a dlouhodobě rozvíjených aplikací odděluji UI, Application, Domain a Infrastructure. Doménová pravidla pak nejsou přilepená na framework, databázi ani konkrétní API a jednotlivé části mají jasnější odpovědnost.
To ale neznamená, že každá část aplikace potřebuje plnou Clean nebo hexagonální architekturu. U jednoduchého problému s několika vstupy a bez složitých pravidel bývá přímé service-based řešení čitelnější a levnější na údržbu.
Neznáte některý z pojmů? Přečtěte si stručné vysvětlení ve slovníku.
Vývoj přístupu
Od Controller → Facade → Service k přiměřeným hranicím.
-
Dříve
Controller → Facade → Service
Tento styl mi dával srozumitelnou strukturu pro tehdejší projekty. Postupně jsem ale u složitějších toků a více integrací narážel na to, že odpovědnosti a závislosti potřebují výraznější hranice. -
Složitější části systému
Oddělení obchodních pravidel od techniky
Když aplikace obsahuje více use cases, integrací nebo pravidel, odděluji doménu a aplikační logiku od HTTP, databáze a frameworku. Tím se lépe testuje, mění a rozšiřuje. -
Dnes
Clean a hexagonální principy podle potřeby
Využívám principy Clean Architecture, DDD, dependency injection a portů s adaptéry. Nejde mi o nálepku ani počet vrstev, ale o jasnou odpovědnost a kontrolované závislosti. -
Pragmatická volba
Kdy je jednodušší řešení lepší
Malý modul bez komplexních pravidel nepotřebuje samostatný domain model, porty ani několik adapterů. V takovém případě volím přímou strukturu a komplexitu přidávám až tehdy, když řeší skutečný problém.
Hranice a závislosti
Obchodní pravidla směrem dovnitř, technické detaily směrem ven.
Vrstvy nejsou samoúčelné. Pomáhají ukázat, kudy smí téct závislosti: UI volá aplikační use case, use case používá doménu a technické detaily implementují rozhraní, která aplikace potřebuje.
Přístup upravuji podle rizika změny, délky života aplikace, počtu integrací i schopnosti týmu architekturu skutečně udržovat.
Port a adaptér
Příklad napojení na externí zdroj dat
- Application: Import výdejních míst
- Port: CarrierPointSource
- Adaptér: XML feed nebo API dopravce
- Infrastructure: HTTP klient, parser a úložiště
Veřejná ukázka
Vrstvy a architektonické kontroly v praxi
Principy, které používám
Architektura podle potřeb aplikace
- Clean Architecture
- DDD
- Hexagonal Architecture
- Dependency Injection
- SOLID
- KISS
- YAGNI
- Deptrac
Potřebujete v aplikaci jasnější hranice, ne více vrstev?
Rád pomohu vyhodnotit, kde architektura přinese skutečný užitek, a kde je lepší zachovat jednoduché a čitelné řešení.