Abstrakt Domain-Driven Design (DDD) představuje přístup k návrhu softwaru, který klade do středu pozornosti porozumění byznysové doméně. Metodika definovaná Ericem Evansem není jen souhrnem technických vzorů, ale především způsobem spolupráce mezi vývojáři a doménovými experty. V éře mikroslužeb a distribuovaných systémů se správné vymezení doménových hranic stává klíčovým faktorem udržitelnosti softwaru. Článek popisuje strategickou i taktickou rovinu DDD, klíčové vzory a praktické aspekty zavedení v podnikovém prostředí.
Proč DDD v moderní architektuře
Tradiční přístup k návrhu softwaru klade důraz na technické vrstvy: databázové schéma, API a uživatelské rozhraní. Byznysová pravidla se často redukují na CRUD operace nad entitami, což vede k anemickému doménovému modelu a k systémům, které je obtížné rozvíjet.
S nástupem mikroslužeb se situace zhoršila. Špatně navržené hranice mezi službami vedou k tomu, co Martin Fowler označuje jako „distributed big ball of mud" – komplexní síť závislostí, kterou není možné udržovat bez koordinované změny několika služeb najednou.
DDD poskytuje nástroje pro:
- identifikaci správných hranic mezi kontexty,
- vytvoření společného slovníku napříč týmy,
- modelování složitých byznysových pravidel,
- vývoj softwaru, který se mění souběžně s byznysovými požadavky.
Strategické DDD
Ubiquitous Language
Společný jazyk (ubiquitous language) je základní koncept DDD. Jde o slovník, který používají všichni účastníci projektu – analytici, vývojáři i doménoví experti. Cílem je odstranit překladovou vrstvu, ve které dochází ke ztrátě informací.
Příklad z praxe: V projektu pro pojišťovnu vývojáři chápali pojem „pojistka" jako databázový záznam. Pro byznys experty se však jednalo o právní dokument s pravidly, výjimkami a životním cyklem. Sjednocení významu na úrovni terminologie a kódu posunulo projekt do správného směru.
Společný jazyk lze vytvářet pomocí:
- workshopů Event Storming s doménovými experty,
- udržovaného slovníku pojmů,
- code review zaměřených na konzistenci pojmenování,
- průběžného refaktoringu při objevu nových souvislostí.
Bounded Context
Ohraničený kontext (bounded context) je hranice, ve které má každý pojem jednoznačný význam. V e-commerce systému má pojem „produkt" různé interpretace:
- v kontextu katalogu: název, popis, fotografie,
- v kontextu skladu: skladové množství a lokace,
- v kontextu expedice: rozměry, hmotnost, křehkost.
Místo jediné rozsáhlé třídy Product vznikají specializované modely pro každý kontext. Hranice kontextů lze identifikovat analýzou byznysových schopností organizace, sledováním rozdílných interpretací pojmů a respektováním Conwayova zákona.
Context Mapping
Ohraničené kontexty neexistují izolovaně. Mapování kontextů popisuje způsoby jejich spolupráce – Partnership, Shared Kernel, Customer/Supplier, Conformist a Anticorruption Layer. Každý vzor řeší jiný typ vztahu a úroveň závislosti mezi týmy.
Taktické DDD
Entity a hodnotové objekty
Entity mají identitu, kterou si zachovávají v čase – typicky zákazník, objednávka nebo uživatelský účet. Hodnotové objekty (value objects) jsou definované svou hodnotou: adresa, peněžní částka, časový interval. Hodnotové objekty by měly být neměnné a porovnávat se podle hodnoty, nikoli podle reference.
Agregáty
Agregát je shluk objektů tvořících hranici konzistence – tedy hranici transakce. Doporučené principy návrhu:
- udržovat agregáty malé, ideálně s jedinou kořenovou entitou,
- odkazovat jiné agregáty pouze přes identifikátor,
- vynucovat byznysové invarianty pouze uvnitř agregátu,
- mezi agregáty pracovat s eventuální konzistencí.
Příkladem je objednávka, která jako kořenový agregát obsahuje řádky a dodací adresu. Agregát zajišťuje, že celková částka nemůže být záporná a že změny stavu odpovídají byznysovým pravidlům.
Doménové služby
Pokud byznysová logika nepatří přirozeně k žádné entitě ani hodnotovému objektu, používá se doménová služba. Typickými příklady jsou převod prostředků mezi účty, výpočet ceny zahrnující pravidla z více agregátů nebo validace napříč agregáty.
Doménové události
Doménové události komunikují změny stavu domény ostatním částem systému. Umožňují oddělení mezi kontexty, zajišťují auditovatelnost a tvoří základ pro Event Sourcing. Implementace se liší podle rozsahu – od in-process pub/sub až po messaging mezi službami.
Repository a aplikační vrstva
Repository poskytuje rozhraní podobné kolekci pro práci s agregáty. Mělo by být zaměřené na doménu, nikoli na CRUD operace. Aplikační služby orchestrují use case – řídí transakce, validují vstupy, vynucují bezpečnostní pravidla a publikují doménové události. Aplikační vrstva nesmí obsahovat byznysovou logiku.
DDD a mikroslužby
Ohraničený kontext představuje přirozenou hranici pro mikroslužbu. Při návrhu architektury platí:
- jeden ohraničený kontext odpovídá jedné službě (ideální stav),
- sdílené části modelu lze oddělit do knihovny,
- doménové události slouží jako integrační události mezi službami,
- konzistence dat napříč službami je řešena eventuálně, nikoli distribuovanými transakcemi.
Práce s legacy systémy
Pro integraci se zastaralými systémy slouží Anticorruption Layer – ochranná vrstva, která překládá data a protokoly mezi novým modelem a legacy systémem. Vzor Strangler Fig umožňuje postupné nahrazování staré funkcionality bez nutnosti rozsáhlé migrace v jednom kroku.
Nejčastější anti-vzory
- Anemický doménový model – objekty obsahují pouze gettery a settery bez chování. Řešením je přesun logiky do doménových objektů.
- Smart UI – byznysová logika v prezentační vrstvě. Řešením je vrstvená architektura a izolace doménového modelu.
- God objects – nadměrně velké agregáty nebo služby. Řešením je dekompozice podle odpovědností.
Organizační aspekty
DDD úzce souvisí s organizační strukturou. Hranice týmů by měly odpovídat hranicím kontextů – stream-aligned týmy vlastní jednotlivé kontexty, enabling týmy poskytují průřezové schopnosti, platformní týmy spravují infrastrukturu. Conwayův zákon platí oboustranně: architektura systému zrcadlí komunikační strukturu organizace.
Závěr
DDD není univerzální řešení a jeho zavedení vyžaduje investici do analýzy domény i do změny pracovních návyků. Přínosy se projevují v dlouhodobém horizontu: ve sjednocené terminologii, jasných hranicích mezi kontexty a ve schopnosti softwaru reagovat na změny byznysových požadavků. Klíčem k úspěchu je začít se strategickou rovinou – ohraničenými kontexty a společným jazykem – a teprve poté přistoupit k taktickým vzorům. Největší chybou bývá opačný postup, kdy týmy aplikují agregáty a repository bez pochopení domény, kterou modelují.
Užitečné odkazy:
