DDD & Microservices
Microservices bez DDD jsou distribuovaný monolith.
Domain-Driven Design definuje správné hranice služeb. Event Sourcing a CQRS řeší konzistenci a výkon. Výsledek: architektura, kde týmy pracují nezávisle.
Proč DDD před microservices¶
Většina neúspěšných microservices architektur má společný problém: služby jsou rozdělené špatně. Auth service, notification service, user service — to jsou technické vrstvy, ne business domény. Výsledek: distributed monolith, kde každá změna vyžaduje koordinaci 3 týmů.
DDD definuje hranice služeb podle business domén. Bounded context = služba. Ubiquitous language = společný slovník business a tech týmu. Výsledek: služby, které se mění nezávisle, protože odpovídají nezávislým business oblastem.
Event Storming — discovery za 2-3 dny¶
Před kódem potřebujete mapu. Event Storming je workshop, kde domain experts a vývojáři společně mapují business procesy:
- Big Picture (půl dne) — Všechny business eventy na timeline. Identifikace hot spots a problémů.
- Process Modeling (1 den) — Detailní flow pro klíčové procesy. Commands, events, policies, read models.
- Software Design (1 den) — Agregáty, bounded contexts, context mapping. Technická architektura z business modelu.
Výstup: mapa systému, které rozumí CTO i product owner. Bounded contexts se přímo mapují na microservices.
Event Sourcing¶
Pro domény vyžadující kompletní historii (finance, audit, compliance):
- Stav = suma eventů. Žádný UPDATE, jen INSERT. Plná rekonstrukce k libovolnému bodu v čase.
- Audit trail zdarma — Každá změna je event s kontextem (kdo, co, kdy, proč).
- Temporal queries — „Jaký byl stav účtu k 31.12.2024?” Triviální dotaz.
- Event replay — Bug fix? Opravte handler, replayujte eventy, stav se opraví.
Kdy NE Event Sourcing: CRUD domény, jednoduché entity bez business logiky, data s vysokou frekvencí změn (IoT telemetrie). Event Sourcing přidává komplexitu — používáme jen tam, kde přináší hodnotu.
CQRS — oddělení čtení a zápisu¶
Command Query Responsibility Segregation:
- Write model — Optimalizovaný na business logiku a konzistenci. Agregáty, invarianty, validace.
- Read model — Optimalizovaný na dotazy. Denormalizované views, materialized projections.
Příklad: Objednávkový systém. Write model validuje business pravidla (sklad, kredit, limity). Read model poskytuje denormalizovaný view pro dashboard (objednávka + zákazník + produkty + stav doručení v jednom dotazu).
Anti-patterns¶
- Shared database — Služby sdílí databázi → tight coupling. Každá služba má vlastní store.
- Synchronní řetězce — A volá B, B volá C, C volá D. Cascade failure. Preferujte asynchronní eventy.
- Nano-services — Příliš malé služby = víc network calls, víc failure points, víc operational overhead.
- God service — Služba, která ví všechno a dělá všechno. Refactor na bounded contexts.
- Distributed transactions — 2-phase commit přes síť. Použijte Saga pattern.
Context Mapping¶
Vztahy mezi bounded contexts:
- Partnership — Dva týmy spolupracují, sdílený cíl
- Customer-Supplier — Upstream dodává, downstream konzumuje
- Anti-Corruption Layer — Ochrana před cizím modelem (typicky legacy integrace)
- Published Language — Sdílený jazyk pro integraci (API contracts)
Context map je živý dokument — aktualizuje se s každou architektonickou změnou.
Časté otázky
DDD dává smysl pro komplexní domény s bohatou business logikou (finance, logistika, pojištění). Pro CRUD aplikace nebo jednoduché API je overkill. Rozhodujeme na základě complexity assessment.
Není magické číslo. Řídíme se bounded contexts z domain modelu. Typicky 5-15 služeb pro středně komplexní systém. Méně je víc — nano-services přinášejí víc problémů než řeší.
Asynchronně přes Kafka (eventy) pro většinu případů. Synchronně přes gRPC/REST pro queries, kde potřebujete okamžitou odpověď. Pravidlo: commands asynchronně, queries synchronně.