Co je Domain-Driven Design?

0:00 – přehrát od tohoto místa Tři týdny na jednu platební metodu

V jednom modelovém e-shopu trvá přidání nové platební metody tři týdny. Samotné napojení platební brány přitom zabere jeden den.

Zbytek padne na opravy toho, co se cestou rozbije. A přesně tenhle stav řeší Domain-Driven Design.

0:27 – přehrát od tohoto místa Když doména přeroste model

Před třemi lety měla objednávka v tom e-shopu tři stavy. Zákazník byl jednoho typu a zaplatit šlo jen jednou metodou.

Dnes je stavů dvanáct. Zákazníci se dělí na čtyři typy a platebních metod je pět. Pro každý typ platí jiné slevy, jiné zacházení s DPH a jiný postup refundace.

Kód mezitím narostl na osmdesát tisíc řádků. Pravidla objednávek jsou rozteklá po servisních třídách.

Když do metody processPayment přidáte větev pro Bitcoin, rozbije se refundace v cancelOrder. Opravíte refundaci a spadne měsíční reporting.

Produktový manažer přitom mluví o rezervaci, která propadne za čtyřiadvacet hodin. V kódu je jen status awaiting payment a týdenní cron, do kterého nikdo nekouká.

Tester pak nahlásí chybu v rezervacích a vývojář skládá chování ze čtyř míst. Žádné z nich přitom nemluví jazykem produktového manažera.

Zkrátka složitost domény přerostla model. A kód mluví jiným jazykem než byznys.

1:54 – přehrát od tohoto místa Definice a Ubiquitous Language

Domain-Driven Design systematicky popsal Eric Evans v knize z roku 2003. Za hlavní riziko složitého softwaru považuje neporozumění doméně, a proto staví její modelování do středu návrhu.

Stručnou definici publikoval až o dvanáct let později, v DDD Reference z roku 2015. Má tři body.

Zaměřit se na Core Domain, tedy na část, kde firma soutěží. Hledat model ve spolupráci s lidmi, kteří doménu znají. A mluvit jedním jazykem uvnitř jasně ohraničeného kontextu.

Když se definice převypráví, jako první z ní vypadne druhá půlka třetího bodu. Jenže jazyk platí jen uvnitř hranice.

Tomu jazyku se říká Ubiquitous Language. Je to společný slovník vývojářů a doménových expertů. Vzniká v konverzaci a dokument je až její záznam.

Třeba když expert opraví vývojáře: to není storno, to je propadnutí rezervace.

Evans k tomu přidává pravidlo, že změna jazyka je změnou modelu. Nový termín od experta si vynutí úpravu kódu.

Nejpraktičtější záznam je glosář v markdownu přímo v repozitáři. Prochází code review a má historii v gitu. Změnu termínu navíc jde svázat s commitem, který přejmenovává třídy.

Pro český tým je rozumný výchozí stav čeština v konverzaci a angličtina v kódu. Glosář pak funguje jako překladová tabulka. Čistě české pojmy jako DPH ale klidně zůstanou česky i v kódu.

3:55 – přehrát od tohoto místa Bounded Context

Žádný model neplatí všude. Bounded Context je hranice, uvnitř které platí jeden model a jeden jazyk.

Vezměte si zákazníka. Objednávky zajímá doručovací adresa, platební metody a kreditní limit.

Podporu zajímá historie komunikace, priorita a otevřené tikety. Platební data ji nezajímají a přístup k nim mít nemá.

Když se oba pohledy slijí do jedné třídy, vznikne objekt s třiceti atributy, ze kterých každý případ užití používá pět. A změna kvůli podpoře pak rozbije objednávky.

Společná zůstává jen identita zákazníka, obvykle jeho ID. A bacha, hranice musí vést i daty. Kontext, který sdílí tabulky s jiným kontextem, hranici prostě nemá.

4:59 – přehrát od tohoto místa Strategický a taktický design, cena DDD

DDD rozhoduje na dvou úrovních. Strategický design dělí systém na kontexty a řeší, jak spolu mluví.

Taktický design modeluje uvnitř jednoho kontextu. Patří sem entity, hodnotové objekty, agregáty, doménové události, repozitáře, doménové služby a továrny.

Sám Evans v roce 2009 řekl, že střed DDD tvoří jazyk, mapování kontextů a Core Domain. Agregáty podle něj krouží hned kolem. A ptal se sám sebe, proč mapování kontextů dal v knize až do čtrnácté kapitoly.

Opačnému přístupu říká Vaughn Vernon DDD-Lite a myslí to jako varování. Tým převezme entity a agregáty a strategickou část přeskočí. Výsledkem bývá jeden model pro celou firmu, jen obalený vzory.

DDD má i svou cenu. Platí se vyšší počáteční složitostí, učením celého týmu a pravidelnou spoluprací s doménovými experty.

Pro CRUD nad jednou tabulkou se nevyplatí. A bez přístupu k doménovému expertovi nefunguje, protože pak nemá kdo říct, jaká pravidla skutečně platí.

Přínosy navíc stojí hlavně na zkušenosti praktiků, ne na měření. Systematický přehled šestatřiceti studií z roku 2023 sice ukazuje zlepšení, jenže části z nich chybí empirické ověření.

6:44 – přehrát od tohoto místa Otázka a shrnutí

Krátká otázka na rozmyšlenou. Kolega navrhne jednu třídu Customer pro objednávky i podporu, ať se nic neduplikuje. Má pravdu?

Nemá. Jsou to dva modely ve dvou kontextech a spojuje je jen ID zákazníka.

Takže v kostce. DDD začíná jazykem a hranicemi, stavební bloky přijdou na řadu až potom.

Uvnitř Bounded Contextu má každý termín jeden význam. A bez složité domény nebo bez doménového experta se DDD nevyplatí.

Příští díl je o subdoménách a o tom, kam modelovací úsilí investovat. Celou kapitolu i se zdroji najdete v knize na ddd-v-symfony.katuscak.cz.