Točím videokurz.
Je ke knize Domain-Driven Design v Symfony 8 a teď vychází na YouTube, kapitola po kapitole. Celkem bude mít 46 dílů, díl má cca 7-13 minut a všechno je česky a zdarma. Díly najdete v playlistu nebo i s přepisem na webu knihy.
Když jsem kurz začal dělat, vrtala mi hlavou jedna otázka. Má smysl dělat kurz o DDD v roce 2026, kdy vám entitu, value object a repozitář vygeneruje agent za pár vteřin? Nechal jsem si od AI udělat rešerši (benchmarky, studie a co k tomu letos řekli třeba Evans nebo Verraes) a tohle z ní vyšlo.
Proč DDD, když kód píše AI?
Smysl to má pořád, jen dnes záleží na jiných částech DDD než dřív.
Samotná znalost taktických vzorů už není tolik důležitá. Jak vypadá entita, value object nebo command handler, agent ví. A když mu napíšete „použij DDD“, vyrobí vám klidně i vrstvy, které vůbec nepotřebujete (cargo-cult DDD s agentem vznikne rychleji než kdy dřív).
Důležitější je to, o čem rozhoduje člověk: kudy vede hranice, jak se věcem ve vaší firmě říká a co musí platit vždycky. Opírá se to o pár dat:
- Agentům pomáhá jasný jazyk a popsaná rozhraní. V benchmarku SWE-Bench Pro (Scale AI, 2025) klesla úspěšnost GPT-5 z 25,9 % na 8,4 %, když autoři z úloh odebrali lidmi napsané požadavky a popis rozhraní. Agent pak prostě nevěděl, jak se věci mají jmenovat a jak má vypadat API. A to je zhruba to, co DDD řeší: ubiquitous language a jasné kontrakty mezi kontexty.
- Čím víc souborů změna zasáhne, tím hůř. Úspěšnost agentů s počtem dotčených souborů prudce klesá. Bounded context je vlastně způsob, jak udržet změnu na jednom místě (jestli líp než jiné rozdělení na moduly, to zatím nikdo neměřil).
- Modely zvládnou jazyk, u agregátů se ztrácejí. V případové studii Eisenreicha a kol. (2026) dělaly modely Claude Opus 4.1, GPT-5 a Gemini 2.5 Pro krok za krokem DDD návrh reálného produktu (šlo ale o jedinou firmu, je to tedy spíš zkušenost než měření). Glosář a mapa kontextů byly použitelné, kontexty jen vyšly rozdrobenější, než jak je má firma ve skutečnosti. U agregátů se ale nasčítaly chyby z předchozích kroků a výsledek už použitelný nebyl. Autoři z toho vyvozují, že se LLM hodí jako sparring partner, ale architekta nenahradí.
A pak je tu protiargument. Kristiyan Stoyanov nechal agenta přidat stejných devět funkcí do dvou verzí jedné služby v Javě, jednou bez vrstev a jednou v hexagonální architektuře. S hexagonální verzí mu práce trvala o 37,8 % déle a spotřeboval zhruba o 70 % víc vstupních tokenů. U šesti těžších úloh byl ale rozdíl jen 8 %. Každá úloha začínala v nové session, a tak se nabízí vysvětlení, že agent musí všechny vrstvy pokaždé číst znovu. Sám Stoyanov přitom píše, že jednoduché vysvětlení v datech nenašel. Je to jeden malý experiment (jedna služba, lokální model, každá úloha proběhla jen jednou), takže to chápu spíš jako varování před vrstvami, které děláte jen ze zvyku, než jako argument proti doménovému modelu.
Kontrolovanou studii typu „DDD zlepšuje výkon agentů o X %“ rešerše nenašla, a kdo uvádí konkrétní procenta, ten si je domýšlí. Podložený je ale samotný princip: agentům pomáhá, když změna zasáhne málo souborů a rozhraní jsou popsaná.
Rešerše končí jednoduchou otázkou, kterou si můžete položit u každého architektonického rozhodnutí: Musí kvůli tomu agent (a kolega) načíst a pochopit méně kódu, nebo víc? Bounded context, glosář nebo invariant hlídaný testem či PHPStanem kódu ke čtení ubírají, ale zbytečný port nebo mapování do DTO mezi každými dvěma vrstvami ho přidávají.
Proč kurz začíná strategií, a ne entitami?
Díly 01-05 jsou o strategickém designu: subdomény (kam investovat a co koupit), bounded contexty a context mapping, Event Storming, Conwayův zákon a Team Topologies. Kódu je v nich málo, a když už nějaký je, ukazuje hlavně, kam co patří (adresáře, namespace, anti-corruption layer na hranici kontextu). Na entity, value objecty a agregáty se pořádně dostanu až v dílu 06.
To pořadí jsem si nevymyslel. Eric Evans v roce 2009 na QCon London řekl, že stavební bloky ve své knize přecenil a hranice kontextů a Core Domain měly přijít dřív. Knihu jsem takhle seřadil hned od první verze a AI v tom žádnou roli nehrála. Jenže teď se ukazuje, že právě se strategickou částí vám agent pomůže nejmíň. Hranice vám klidně navrhne, ale jestli sedí na vaši firmu a tým, musí pořád rozhodnout člověk.
A jeden celý díl (22) je o tom, kdy DDD nepoužívat. Pro CRUD je plné DDD zbytečná režie a s agentem je ta režie ještě vyšší. Agenti zvládají CRUD nejlíp a každá vrstva navíc stojí tokeny.
Jak vypadá jeden díl?
Každý díl patří k jedné kapitole knihy a má i její číslo, takže můžete přeskakovat mezi videem a textem. Kapitoly jsou ale dlouhé, a tak jsem skoro všechny (21 z 24) rozdělil na dva díly (03a, 03b…). Proto jich je 46, a ne 25 (předmluva + 24 kapitol).
Kudy začít?
Projít celý kurz jde od prvního dílu po poslední, ale málokdo to potřebuje. Většina lidí přijde s konkrétním problémem. Číslo dílu = číslo kapitoly, takže doporučené cesty z předmluvy knihy platí i pro kurz:
| Kdo jste | Díly |
|---|---|
| Junior / medior, s DDD začínáte | 01 → 06 → 07 → 10 → 17 |
| Senior se službou na 1 500 řádků | 07, 08, 21 |
| Architekt | 01, 02, 03, 05, 18, 19, 21, 22, 24 |
| Tech lead | 05, 04, 18, 20, 21, 22 |
| Přecházíte z CRUD | 01, 22, 02, 06, 07, 18, 20 |
Pokud vás zajímá hlavně ta AI část, doporučuju díly 02 a 03 (subdomény a hranice) a k nim kapitolu DDD a umělá inteligence, kde jsem sepsal, co si o DDD a AI myslí Evans, Fowler, Beck, Tune, Brandolini a další.
Nové díly vycházejí každý všední den v 7:00 a aktuální přehled je vždycky na webu knihy. Celý kurz bude venku zhruba za dva měsíce (vydávání dílů jednou týdně by trvalo skoro rok).
Proč to vlastně dělám?
DDD jsem se učil sám. Z knih, z cizích článků a hlavně metodou pokus–omyl na vlastních projektech. Česky k tomu skoro nic nebylo, a už vůbec ne s PHP. Nejdřív vznikla kniha, pak hra o hranicích a teď kurz pro ty, kdo se radši dívají, než čtou (což je i pro mě příjemnější forma jak do sebe dostat nové informace).
Jestli vám díl pomůže, nejvíc mi uděláte radost, když ho pošlete kolegovi, který zrovna kreslí hranice v novém projektu. A když najdete chybu, napište mi a opravím ji v knize i ve videu :)
Zdroje
- SWE-Bench Pro (Scale AI, 2025): https://www.alphaxiv.org/abs/2509.16941
- Eisenreich a kol., případová studie DDD s LLM (2026): https://arxiv.org/pdf/2603.26244v1
- Kristiyan Stoyanov, hexagonální vs. plochá architektura s agentem: https://dev.to/kstoyanovai/i-expected-hexagonal-architecture-to-help-my-coding-agent-it-didnt-3blg
- Eric Evans, QCon London 2009: viz předmluva knihy