Kapitola 01 · Základy · Co je Domain-Driven Design?

Co je Domain-Driven Design?

Domain-Driven Design (DDD), jeho základní principy a způsob, jakým pomáhá řešit složité domény a zlepšuje komunikaci mezi vývojáři a doménovými experty.

Autor M. Katuščák
Doba čtení ≈ 12 min
Náročnost základní
Publikováno · Aktualizováno ·
Obsah kapitoly

Než se ponoříme do definic, podíváme se na konkrétní situaci, ve které DDD pomáhá. Modelový e-shop, který tým rozjel před třemi lety, měl tehdy tři stavy objednávky (new, paid, shipped), jeden typ zákazníka a jednu platební metodu. Doménový model byl triviální. Doctrine entita Order měla šest sloupců, OrderService dvě stě řádků, kontroler tři metody. Tým měl tři lidi a každou novou funkci dodal za týden.

Po třech letech provozu vypadá doména jinak. Stavů objednávky je dvanáct: new, awaiting_payment, paid, partially_paid, held_for_review, confirmed, shipped, delivered, cancelled, refunded, disputed, returned. Typů zákazníka jsou čtyři: B2C, B2B s fakturací, dealer s rabatem, partner s vlastním ceníkem. Platebních metod pět: karta přes Stripe, Apple Pay, bankovní převod, dobírka, faktura splatná do 30 dnů. Každý typ zákazníka má jiná pravidla pro slevy, jiné zacházení s DPH a jiný proces refundace.

Tým má teď pět lidí, kód má 80 000 řádků a přidání nové platební metody (Bitcoin přes BitPay) trvá tři týdny. Ne proto, že integrace s BitPay je složitá – ta je hotová za den. Ale protože každá změna v OrderService rozbije něco jiného. Když přidáte větev pro Bitcoin v metodě processPayment, rozbije se refund logika v cancelOrder. Když opravíte refund, rozbije se reporting v MonthlyRevenueService. Po třech týdnech ladění a regresních testů je BitPay v produkci, ale tým má dvouměsíční technický dluh v backlogu.

Senior vývojář si všiml, že kód odráží něco jiného než to, co produktový manažer popisuje. PM mluví o „závazné objednávce po kliknutí na platbu“ a o „rezervaci, která propadne za 24 hodin“. V kódu je Order::status = 'awaiting_payment' a TTL kontrola se schovává v týdenním cronu, do kterého nikdo nekouká. Když tester nahlásí bug v rezervační logice, je třeba přečíst OrderService::checkExpiration, WeeklyCleanupCommand, OrderEventSubscriber a OrderRepository::findExpiredAwaitingPayment, než je celé chování pohromadě. Doménová pravidla žijí roztroušená napříč pěti soubory bez společného slovníku.

Onboarding nového kolegy trvá dva měsíce, než začne dělat smysluplné PR. Ne proto, že by Symfony bylo komplikované – Symfony zná po týdnu. Ale doménová pravidla jsou v hlavách dvou seniorů a v kódu jsou jen jejich důsledky. Junior se ptá: „proč při refundaci nezapočítáváme dopravu, ale při dispute ano?“ Odpověď zní: „protože kdysi to chtěl účetní“. Není to nikde dokumentované.

Ředitel se ptá CTO: proč nedokážeme přidat novou platební metodu rychleji než za tři týdny? Konkurence to umí za týden. CTO ví, že problém není v nástrojích – problém je v tom, jak je modelovaná doména. Kód neodráží reálné rozhodování byznysu. Každá feature musí znovu dohledávat, co kde sedí, jaké pravidlo platí v jakém stavu, kdo má autoritu rozhodnout, že refund jde, a kdy ne.

Komplexita domény přerostla model – právě tento stav DDD řeší. Nabízí konkrétní odpověď: místo OrderService::cancelOrder($order, $reason) mít doménový model Order s explicitními metodami confirm(), cancel(), dispute(), refund(). Místo textového statusu mít stavový automat s explicitními přechody. Místo čtyř typů zákazníka v jednom modelu mít čtyři Bounded Contexts, kde každý má svého Customer s vlastními atributy a vlastními pravidly. Místo měsíců regresí mít hranice agregátů, které drží refaktoring v rozumných mezích.

Hlavní přínos DDD: kód odráží jazyk, kterým mluví doménoví experti. Když produktový manažer řekne „tohle není reklamace, je to dispute s odlišným procesem“ – kód to umí říct stejně. Když účetní rozhoduje, jestli refund započítává dopravu, doménová třída Refund má metodu excludeShipping() nebo includeShipping(), která to říká. Když tester píše scénář, používá stejný slovník jako PM. Slovník je jeden, žije v hlavě týmu i v kódu, a když se mění, mění se na obou místech najednou.

DDD má svou cenu. Vyžaduje vyšší počáteční složitost, učební křivku týmu a opakovanou spolupráci s doménovými experty. Pro CRUD aplikaci nad jednou tabulkou se nevyplatí – tam je OrderService se setterem správná volba a investice do agregátu by byla nepřiměřená. Pro komplexní doménu s rostoucí pravidlovou složitostí, kterou tým udržuje déle než rok, se DDD vrací v horizontu šesti až dvanácti měsíců.

V této knize se naučíte, jak rozhodnout, jestli DDD ve vašem projektu dává smysl (kapitola Kdy DDD nepoužívat je o tom, kdy odpověď zní „ne“). Jak modelovat doménu, identifikovat agregáty, oddělit zápis od čtení. Jak to konkrétně implementovat v Symfony 8 – bez teoretických odboček, s funkčním kódem, který lze převzít.

A teď k definicím.

01.01 Definice DDD#

Softwarové projekty podle rozšířené zkušenosti selhávají častěji kvůli neporozumění problémové oblasti než kvůli technickým chybám. Domain-Driven Design (DDD) na to odpovídá tím, že modelování domény staví do středu celého návrhu. Systematicky jej popsal Eric Evans v knize Domain-Driven Design: Tackling Complexity in the Heart of Software z roku 2003 [1].

01.02 Historie a vývoj DDD#

Hlavní milníky ve vývoji DDD [6]:

  • 2003 – Eric Evans vydává knihu Domain-Driven Design: Tackling Complexity in the Heart of Software, která zavádí základní pojmy: Ubiquitous Language, Bounded Context, Aggregate a strategický/taktický design.
  • 2013 – Vaughn Vernon vydává Implementing Domain-Driven Design, která přináší praktické příklady a propaguje vzory jako Aggregate design, Domain Events a CQRS v kontextu DDD.
  • 2013 – Alberto Brandolini představuje Event Storming – workshopovou techniku pro kolaborativní modelování domény s doménovými experty.
  • 2016 – Vaughn Vernon vydává Domain-Driven Design Distilled, zkrácenou a přístupnější verzi pro rychlé pochopení hlavních konceptů.
  • Po roce 2015 – DDD si nachází přirozené uplatnění v mikroservisové architektuře: Bounded Context se stává standardním vodítkem pro určení hranic jednotlivých služeb [7].

01.03 Ubiquitous Language v praxi#

Ubiquitous Language nevzniká sepsáním dokumentu. Vzniká konverzací – v plánovací schůzce, při Event Stormingu, v diskuzi nad bugem, kde doménový expert opraví vývojáře: „to není storno, to je propadnutí rezervace“. Dokument je až záznam této konverzace. Pokud tým začne dokumentem, vznikne slovník, kterým nikdo nemluví.

Praktická forma záznamu: glosář jako markdown soubor v repozitáři, vedle kódu. Ne wiki stránka, ne sdílený dokument v cloudu. Důvod je provozní – glosář v repozitáři prochází code review, má historii v gitu a změna termínu se dá svázat s commitem, který přejmenovává třídy. Glosář udržuje celý tým: kdo termín do kódu zavádí nebo mění, otevírá zároveň PR do glosáře. Doménový expert recenzuje význam; zápis a údržba zůstávají na vývojářích.

Čeština v konverzaci, angličtina v kódu

Český tým řeší otázku, kterou Evans neřešil: doménoví experti mluví česky, identifikátory v kódu jsou zvykově anglické. Doporučený výchozí stav: čeština v konverzaci a glosáři, angličtina v identifikátorech kódu. Glosář pak slouží jako překladová tabulka – každý český termín má závazný anglický ekvivalent a o překladu rozhoduje tým, ne jednotlivý vývojář u klávesnice. Bez tabulky vznikne pro „propadnutí rezervace“ trojí překlad – ve třech třídách expire, lapse a timeout.

Čeština přímo v identifikátorech dává smysl u čistě české domény, pro kterou angličtina nemá ustálený termín. DPH není totéž co VAT v jiné jurisdikci, „datová schránka“ nemá anglický ekvivalent vůbec a překlad DataBox význam spíš zamlžuje. Třída DatovaSchranka nebo DphSazba je v takovém kódu přesnější než vymyšlený anglicismus. Hranici si tým stanoví v glosáři: termíny označené jako nepřeložitelné zůstávají česky.

Signály eroze jazyka

Jazyk eroduje tiše. Tři signály, které erozi prozradí dřív než produkční incident:

  • PM mluví o „rezervaci, která propadne za 24 hodin“, kód má Order::status = 'awaiting_payment' a cron job. Stejný koncept, dva slovníky – přesně situace z úvodu této kapitoly.
  • Na schůzce se překládá. Jakmile vývojář větu experta v duchu převádí („tím myslí náš PendingOrder“), model a doména se už rozešly.
  • Nový kolega se zeptá, co znamená termín z glosáře, a dostane odpověď „to už se nepoužívá“. Mrtvý glosář je horší než žádný – dokumentuje neexistující jazyk.

Odpověď na erozi je vždy stejná: srovnat kód s jazykem expertů, ne naopak. Přejmenování třídy je levné. Tým, který rok mluví jiným jazykem než jeho kód, platí překladem při každé konverzaci.

Ukázka glosáře

markdown docs/domain/glosar.md 
1# Glosář – kontext Objednávky (Ordering)2 3| Český termín | Identifikátor v kódu | Význam | Pozn. |4|---|---|---|---|5| objednávka | `Order` | Závazek zákazníka po kliknutí na „Zaplatit“. | |6| rezervace | `Reservation` | Blokace zboží před zaplacením, propadá za 24 h. | Není to objednávka! |7| propadnutí rezervace | `Reservation::expire()` | Automatické uvolnění blokace po TTL. | Ne „storno“. |8| storno | `Order::cancel()` | Aktivní zrušení zákazníkem nebo operátorem. | |9| dispute | `Dispute` | Sporná platba řešená s bránou. | Jiný proces než reklamace. |10| DPH | `Dph`, `DphSazba` | Česká sazba daně vč. přenesené povinnosti. | Nepřekládat na VAT. |11 12Změny: každá úprava termínu = PR s odkazem na commit,13který přejmenovává odpovídající třídy. Reviewer: doménový expert.

Glosář nemá ambici být úplný. Zachycuje termíny, u kterých hrozí záměna – dvojice jako rezervace/objednávka nebo storno/propadnutí, kde chybný překlad znamená chybné chování systému.

01.04 Strategický design (Strategic Design)#

FIG. 01.4-A Strategický vs. taktický design – dvě úrovně rozhodování v DDD

Strategický design rozhoduje, jak rozdělit systém na samostatné části a jak spolu komunikují. Hlavní koncepty:

  • Bounded Context – Ohraničený kontext je explicitně vymezená oblast, uvnitř které platí jeden doménový model. Plná definice s příkladem následuje v podsekci níže.
  • Context Map – Mapa kontextů zobrazuje vztahy mezi různými bounded contexts. Tyto vztahy mohou být různého typu, například Partnership, Customer-Supplier, Conformist nebo Anti-Corruption Layer.
  • Shared Kernel – Část modelu společná dvěma nebo více bounded contexts. Vyžaduje úzkou spolupráci mezi týmy.
  • Customer-Supplier – Vztah zákazník-dodavatel mezi dvěma bounded contexts, kde jeden kontext (dodavatel) poskytuje služby druhému kontextu (zákazník).
  • Conformist – Vztah, kde jeden kontext přijímá model jiného kontextu bez možnosti jej ovlivnit.
  • Anti-Corruption Layer – Vrstva, která překládá mezi dvěma bounded contexts s různými modely, aby chránila integritu cílového modelu.
  • Open Host Service – Služba, která definuje protokol pro přístup k bounded contextu, aby usnadnila integraci s mnoha jinými kontexty.
  • Komunikaci mezi kontexty usnadňuje dobře dokumentovaný Published Language.

Bounded Context: hranice platnosti modelu

Žádný model neplatí všude. Každý je zjednodušením domény pro určitý účel, a mimo tento účel přestává dávat smysl. Bounded Context je explicitní hranice, uvnitř které jeden model a jeden Ubiquitous Language platí beze zbytku. Uvnitř hranice má každý termín právě jeden význam. Co je za ní, model záměrně ignoruje.

Tentýž pojem označuje v různých kontextech jiný model. V e-shopu existuje Customer v kontextu Ordering i v kontextu Support, ale jsou to dva různé objekty. Ordering zajímá doručovací adresa, platební metody, kreditní limit a historie objednávek; invarianty se točí kolem placení. Support vidí kontakt s komunikační historií, prioritou SLA a otevřenými tikety; platební data ho nezajímají a nemá k nim mít přístup. Společná je jen identita zákazníka – obvykle ID, přes které se oba modely propojují.

Pokus oba pohledy sloučit do jedné třídy Customer vede ke známému výsledku: objekt s třiceti atributy, z nichž každý use case používá pět, a s pravidly, která si vzájemně překáží. Jedna změna pro podporu rozbije fakturaci. Oddělené modely v oddělených kontextech tento konflikt odstraňují – každý model je malý, úplný a vnitřně konzistentní.

Explicitní hranice znamená explicitní překlad. Když Ordering potřebuje data ze Support (nebo naopak), komunikace jde přes definované rozhraní a pojmy se na hranici překládají – třeba přes Anti-Corruption Layer z předchozího seznamu. Překlad není režie navíc; je to zviditelnění práce, která jinak probíhá skrytě a chybově uvnitř sdíleného modelu.

Bounded Context je proto i hranicí jazyka. „Rezervace“ může v kontextu Ordering znamenat blokaci zboží, v kontextu Logistics časové okno doručení. Oba významy jsou správně – každý ve svém kontextu. Implementaci Bounded Contexts rozvádí kapitola o základních konceptech, vztahy mezi kontexty pak kapitola o Context Mappingu.

01.05 Taktický design (Tactical Design)#

Taktický design řeší konkrétní implementaci doménového modelu uvnitř jednoho bounded contextu. Hlavní vzory:

  • Entity – Objekty s identitou a kontinuitou v čase. Definuje je identita, nikoli atributy. Například zákazník v e-shopu je entita, protože má unikátní identifikátor (CustomerId), i když se jeho ostatní atributy (jméno, e-mail, adresa) v průběhu času mění.
  • Value Object – Hodnotové objekty jsou definovány svými atributy, nikoli identitou. Jsou neměnné (immutable) a používají se k popisu aspektů domény. Typickým příkladem hodnotového objektu je adresa nebo peněžní částka.
  • Aggregate – Agregát je skupina objektů, která tvoří jednu jednotku konzistence při zápisu dat. Každý agregát má kořen agregátu (Aggregate Root), který je jediným vstupním bodem pro veškeré vnější interakce s agregátem.
  • Domain Event – Doménová událost reprezentuje něco, co se stalo v doméně a má význam pro doménové experty. Slouží mimo jiné ke komunikaci mezi různými bounded contexts.
  • Service – Doménová služba implementuje doménovou logiku, která nepatří přirozeně do žádné entity nebo hodnotového objektu. Služby jsou bezstavové a jejich názvy by měly být odvozeny z Ubiquitous Language.
  • Repository – Repozitář zapouzdřuje logiku pro přístup k persistenci agregátů. Poskytuje abstrakci nad datovým úložištěm a umožňuje pracovat s agregáty jako s objekty v paměti.
  • Vytváření složitých objektů a agregátů zapouzdřuje Factory (továrna). Hodí se, když konstrukce vyžaduje víc kroků nebo když nově vzniklý objekt musí od počátku splňovat invarianty.
FIG. 01.5-A Agregát v e-commerce doméně

01.06 Implementace DDD v praxi#

Typický postup zavedení DDD má osm kroků. První čtyři patří strategickému designu (kontexty, jazyk), zbytek taktickému designu a iteraci modelu.

  1. Pochopení domény – Začíná rozhovory s experty, workshopy, modelováním na tabuli. Bez této fáze model padá hned na začátku.
  2. Ubiquitous Language – Společný slovník vývojářů a doménových expertů, zapsaný a průběžně aktualizovaný. Stejné pojmy v kódu, dokumentaci i mailu od PM.
  3. Identifikace Bounded Contexts – Doména se rozděluje na menší kontexty s explicitními hranicemi. Každý kontext má vlastní model.
  4. Context Map – Vztahy mezi kontexty (Customer-Supplier, Conformist, Anti-Corruption Layer) jsou popsané a mají odpovědné týmy.
  5. Doménový model – Entity, Value Objects, agregáty, doménové služby a události jsou navrženy a implementovány v každém kontextu samostatně.
  6. Implementace – Vrstvená nebo hexagonální architektura odděluje doménový model od infrastrukturní vrstvy.
  7. Testování – Doménový model má pokrytí unit testy, hraniční scénáře integrační testy.
  8. Iterace – Model se průběžně upravuje, jak roste pochopení domény. DDD není jednorázová investice.

01.07 Výhody používání DDD#

Co konkrétně tým získá, když DDD nasadí správně:

První přínos je v komunikaci. Ubiquitous Language odstraňuje nedorozumění mezi vývojáři a doménovými experty, protože všichni používají stejné pojmy v kódu i v konverzaci. S tím souvisí odolnost vůči změnám: model orientovaný na doménu je stabilnější než model orientovaný na databázové schéma a změny v obchodních požadavcích se do něj promítají přirozeněji.

  • Modularita – Bounded Contexts umožňují nezávislý vývoj, nasazení a škálování jednotlivých částí systému.
  • Testovatelnost – Doménové objekty bez infrastrukturních závislostí lze testovat v izolaci bez mockování (viz kapitola o testování).
  • Snížení technického dluhu – Explicitní doménový model slouží jako živá dokumentace systému, která zůstává aktuální s kódem.
  • Zaměření na hodnotu – DDD rozlišuje Core Domain (zdroj konkurenční výhody) od podpůrných domén. Investice se pak soustředí tam, kde přinášejí největší obchodní hodnotu.

Praktické příklady Ubiquitous Language a dalších konceptů naleznete v kapitole Základní koncepty DDD.

01.08 Výzvy a omezení DDD#

DDD má reálné náklady, se kterými rozhodnutí o nasazení musí počítat:

  • Složitost – hluboké pochopení domény i architektonických principů; pro vývojáře bez zkušenosti s objektovým modelováním velký skok.
  • Časová náročnost – V počátku projektu se modelování domény a budování Ubiquitous Language nevrací rychle. Investice se vrátí až s rostoucí složitostí pravidel.
  • Nevhodnost pro jednoduché aplikace – U CRUD aplikací s minimální doménovou logikou DDD přidává režii bez návratnosti.
  • Integrace s legacy systémy – Napojení DDD modelu na starý systém typicky vyžaduje Anti-Corruption Layer, který má vlastní cenu.
  • Výkonnost – Při špatné implementaci hrozí problém N+1 a načítání zbytečně velkých grafů.

K tomu se přidává lidská stránka. Bez přístupu k doménovému expertovi nemá kdo říct, jaká pravidla skutečně platí. Spolupráce vývojářů s experty navíc znamená pravidelné workshopy a sdílený jazyk – a některé organizace na to nejsou nastavené. Tým sám potřebuje měsíce, než získá rutinu; první projekt v DDD bývá pomalejší než stejný projekt v CRUD.

01.09 DDD vs. jiné přístupy#

DDD se v praxi nejčastěji srovnává se čtyřmi jinými přístupy. Žádný z nich není přímý konkurent. Některé řeší jinou vrstvu problému; jiné pro jednodušší domény stačí samy o sobě:

  • DDD vs. Transaction Script – Transaction Script (Martin Fowler, PoEAA) organizuje logiku kolem případů užití: každý use case je jedna procedura, která čte data, aplikuje pravidla a ukládá výsledek. Rozdíl: Transaction Script nemá doménový model – logika je v procedurách, ne v objektech. Pro jednoduché domény je to přímočařejší; s rostoucí složitostí se pravidla duplikují a kód se hůř udržuje. DDD je vhodnější, jakmile stejná doménová pravidla sdílí více use cases.
  • DDD vs. CRUD – CRUD (Create, Read, Update, Delete) je datově orientovaný přístup: aplikace je v podstatě editor databázových tabulek. Rozdíl: CRUD nerozlišuje mezi doménovým chováním a datovými operacemi – každá akce je variací na čtení/zápis řádku. DDD naproti tomu modeluje chování domény (objednávku nelze jen „updatovat“, ale „potvrdit“, „zrušit“ nebo „odeslat“). Pro jednoduchou správu dat CRUD postačí.
  • DDD vs. Hexagonální architektura – Hexagonální architektura (Ports and Adapters, Alistair Cockburn) řeší jak strukturovat závislosti: doménové jádro komunikuje s vnějším světem přes porty (rozhraní) a adaptéry (implementace). Rozdíl: DDD řeší jak modelovat doménu (Entity, Value Objects, Aggregates), hexagonální architektura řeší jak oddělit doménu od infrastruktury. Doplňují se: DDD nabízí vzory pro doménové jádro, hexagonální architektura ho izoluje od infrastruktury. Volbu mezi hexagonální, onion a clean architekturou rozvádí kapitola o architektonických stylech.
  • DDD vs. Mikroservisy – Mikroservisy jsou architektonický styl zaměřený na jak nasazovat a škálovat části systému nezávisle. Rozdíl: DDD řeší logické hranice domény (Bounded Contexts), mikroservisy řeší fyzické hranice nasazení. Bounded Context z DDD je přirozeným kandidátem pro hranici mikroservisy, ale neplatí to automaticky – jeden Bounded Context lze implementovat jako více mikroservis a naopak. DDD lze nasadit i v monolitické architektuře.

01.10 Shrnutí#

DDD strukturuje práci do tří vrstev. Každá má jiné odpovědnosti:

  • Strategický design – Bounded Contexts, Context Map, Ubiquitous Language
  • Taktický design – Entity, Value Objects, Aggregates, Repositories, Domain Events, Services, Factories
  • Implementační vzory – Anti-Corruption Layer, Specification, Saga / Process Manager

DDD se osvědčuje v aplikacích s bohatou doménou, kde přesné modelování obchodní logiky přináší měřitelnou hodnotu. Má reálné náklady – naučení se vzorů, vyšší počáteční složitost, nutnost spolupráce s doménovými experty – a proto vyžaduje vědomé rozhodnutí.

Časté otázky

Co je Domain-Driven Design?

Domain-Driven Design (DDD) je přístup k vývoji softwaru, který staví modelování domény do středu celého návrhu. Systematicky jej popsal Eric Evans v knize z roku 2003. Cílem je, aby software co nejpřesněji odrážel způsob, jakým v dané oblasti uvažují doménoví experti, a aby tento soulad vydržel i při růstu aplikace. Podrobnosti v sekci Definice DDD.

Co je Ubiquitous Language v DDD?

Ubiquitous Language (všudypřítomný jazyk) je společný slovník používaný vývojáři i doménovými experty při návrhu, diskuzi i implementaci systému. Stejné pojmy se objevují v doménové dokumentaci, v rozhovorech nad modelem i přímo v kódu. Tím se eliminují nedorozumění a snižuje se riziko, že kód bude modelovat něco jiného, než doména skutečně potřebuje. Více v sekci Ubiquitous Language v praxi.

Co je Bounded Context a k čemu slouží?

Bounded Context (ohraničený kontext) je explicitně definovaná hranice, uvnitř které platí jeden konzistentní doménový model a jeden Ubiquitous Language. Mimo tuto hranici mohou stejné pojmy znamenat něco jiného – například „Customer“ ve fakturaci a „Customer“ v podpoře jsou různé modely s různými atributy. Bounded Contexts pomáhají rozdělit složitou doménu na menší zvládnutelné části a bývají přirozenými hranicemi pro mikroservisy. Viz podsekce o Bounded Contextu.

Kdy se DDD nevyplatí použít?

Stručně: DDD nepřináší odpovídající hodnotu u projektů s triviální doménovou logikou, v týmech bez přístupu k doménovým expertům a při krátkém horizontu produktu. Detailní rozbor podmínek, příznaků a alternativ obsahuje samostatná kapitola Kdy DDD nepoužívat.

01.11 Další četba#

Hlavní zdroje:

01.12 Jak číst tuto knihu#

Tato kapitola je první v sekvenci 24 kapitol. Pořadí kapitol je promyšlené – každá staví na předchozích – ale málokdo potřebuje lineární čtení od první do poslední. Většina čtenářů má konkrétní bolest a kniha je připravená na selektivní čtení.

Pro detailní cesty čtení podle role (junior/mid Symfony developer, senior PHP developer, architekt, tech lead, vývojář migrující z CRUD) projděte Předmluvu, sekci 'Jak číst tuto knihu'. Stručný přehled částí knihy:

  • Strategický design (kap. 2–5) odpovídá na otázku kde DDD aplikovat. Subdomény, Bounded Contexts, Event Storming, Team Topologies. Pokud z této kapitoly odejdete s pocitem, že DDD ve vašem projektu nedává smysl, kapitoly 2–5 vám potvrdí proč. Pokud má smysl, dají vám nástroj, jak začít.
  • Taktický design (kap. 6–9) pokrývá konkrétní stavební bloky: entity, hodnotové objekty, agregáty, doplňující vzory, architektonické styly. Nejdůležitější je návrh agregátu – nejtěžší rozhodnutí v taktickém DDD.
  • Implementace v Symfony (kap. 10–11) překládá teorii do konkrétního Symfony 8 kódu s Doctrine ORM, Messenger a aktuálními PHP rysy. Plus autorizace ve čtyřech vrstvách.
  • Pokročilé vzory (kap. 12–15) obsahují CQRS, Event Sourcing, Ságy a Outbox Pattern. Tyto vzory nejsou pro každý projekt – kapitoly začínají rozhodovacím rámcem, kdy ano a kdy ne.
  • Výkon a testování (kap. 16–17), migrace a microservices (kap. 18–19), provozní problémy, anti-vzory a kdy DDD nepoužívat (kap. 20–22), praktické příklady (kap. 23–24) uzavírají knihu.

Pokud váháte, jestli má vůbec smysl pokračovat, nabízí se tento postup. Přečtěte si tuto kapitolu (1) a kapitolu Kdy DDD nepoužívat. Pokud po obou kapitolách máte pocit, že DDD ve vašem projektu dává smysl, pokračujte na kapitolu 2 Subdomény. Pokud váháte, projděte ještě Cheat Sheet – jednostránkový přehled pro rychlou orientaci.

Pro definice termínů slouží Glosář. Pro citace knih a článků v každé kapitole je sekce „Další četba“ (jako tato).