Kapitola 00 · Úvod · Předmluva

Předmluva

Co je tato kniha, pro koho je, jak je strukturovaná a jak ji číst podle role čtenáře.

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

Videokurz ke knize

Celý videokurz
  1. Kapitoly videa a přepis dílu 00 →

Přehrávač YouTube se načte až po kliknutí.

Kniha vychází z opakované situace. Vývojář otevře Domain-Driven Design: Tackling Complexity in the Heart of Software od Erica Evanse, přečte 560 stran bez jediného řádku PHP a zavře ji se dvěma otázkami. Kde začít? A jak to konkrétně udělat v Symfony? Mezi textem z roku 2003 a PHP projektem v roce 2026 leží vrstva implementačních detailů, kterou Evans pokrýt nemohl. Vaughn Vernon ji v Implementing Domain-Driven Design (2013) rozepsal na příkladech v Javě.

PHP literatura k DDD existuje a tento text ji nenahrazuje. Domain-Driven Design in PHP (Buenosvinos, Soronellas, Akbary) vyšlo v roce 2017 a druhé vydání žije dál na Leanpubu. Matthias Noback pokrývá v Advanced Web Application Architecture (2020) architekturu aplikace jako celek. Oba tituly míří jinam. První je podrobný v taktických vzorech a hexagonální architektuře, strategickému designu ale dává málo prostoru a se Symfony 8 soustavně nepracuje. Noback řeší stavbu aplikace, ne DDD. Česky k tématu nevyšlo nic.

Zbývá užší mezera: DDD od strategických rozhodnutí až po kód, který běží na aktuálním Symfony. Kniha začíná otázkou, kdy se DDD vůbec vyplatí. Pokračuje přes strategický a taktický design ke konkrétním ukázkám s Doctrine ORM 3, Symfony Messenger a PHP 8.4. Ukázky jsou funkční kód, ne pseudokód.

P.01 Pro koho je tato kniha#

Kniha předpokládá zkušenost s PHP a Symfony, objektově orientovaným programováním a základními designovými vzory. Nepředpokládá zkušenost s DDD. Kdo zná Symfony Controller, Doctrine entitu a Dependency Injection a chápe rozdíl mezi interface a abstraktní třídou, má vše potřebné.

Kniha počítá s pěti typickými čtenáři:

  • Senior PHP developer, který v projektu narazil na limity klasické vrstvené architektury. OrderService má 1500 řádků, každá nová feature rozbije něco jinde a zaučení nového kolegy trvá měsíce.
  • Junior/mid Symfony developer, který si všiml, že větší projekty „rostou“ jinak než malé, a hledá strukturovanější přístup než jen Controller-Service-Repository.
  • Architekt, který volí přístup k modelování doménové logiky: DDD, klasické CRUD, modulární monolit, nebo microservices.
  • Tech lead, který musí svému týmu vysvětlit, proč a jak DDD zavést, a hledá argumenty pro management opřené o DORA metriky a obchodní hodnotu.
  • Poslední je vývojář migrující z CRUD aplikace na DDD. V produkci má spaghetti kód a hledá cestu ven po malých krocích.

Každá role má vlastní doporučenou cestu čtení; popisuje je P.03 Jak číst tuto knihu.

Co tato kniha není

  • Ne úvod do PHP nebo Symfony. Pokud Symfony vidíte poprvé, projděte nejprve oficiální Symfony dokumentaci.
  • Ne kuchařka „kopíruj-vlož“. Kód ilustruje vzory v kontextu, ne hotová řešení pro váš projekt. DDD vyžaduje úsudek nad doménou, ne mechanické dosazování šablon.
  • Ne kompletní reference DDD. Pro hlubší teoretický základ čtěte Evanse (2003), Vernona (2013) a Khononova (2021). Odkazy na konkrétní pasáže najdete přímo v textu kapitol a v přehledu zdrojů.
  • Ne záruka, že DDD u vedení prosadíte. Měřitelné argumenty kniha dodává a DORA metrikám a komunikaci s managementem věnuje vlastní sekci. O výsledku jednání ale rozhoduje spíš organizace než kvalita argumentu.
  • Ne referenční příručka Doctrine ani Messengeru. Obě komponenty text používá jen v rozsahu, který DDD potřebuje. Detaily mapování, DQL nebo transportů hledejte v dokumentaci knihoven.

Předpoklady

Výchozí znalosti:

  • PHP 8.4+: atributy (#[Attribute]), enums, readonly properties, named arguments, match a asymetrická viditelnost (public private(set)). Na novějším PHP kód běží beze změny.
  • Symfony 8+: Service Container, Dependency Injection, Doctrine ORM 3, Symfony Messenger, atributy #[Route], #[AsMessageHandler].
  • Objektově orientované programování: dědičnost vs. kompozice, polymorfismus, zapouzdření, SOLID principy.
  • Designové vzory: Repository, Factory, Strategy, Observer. Formální znalost nutná není, stačí je v kódu poznat.
  • Relační databáze: ACID, transakce, indexy, JOIN, optimistický a pesimistický zámek.

Ke stacku ještě poznámka pro zakládání projektu. Symfony vydává minor verze každých šest měsíců a udržuje je krátce; dlouhou podporu má vždy až poslední minor v major řadě. Aktuální LTS je v září 2026 Symfony 7.4. Vystačí si s PHP 8.2 a běží i s Doctrine ORM 2, jenže na takovém stacku část ukázek neběží: asymetrická viditelnost public private(set) vyžaduje PHP 8.4 a ORM 3 se v řadě míst chová jinak než dvojka.

Kniha proto cílí na Symfony 8, jehož první LTS se čeká až koncem roku 2027. Do té doby knihu plně využije ten, kdo drží aktuální stabilní verzi a počítá s upgradem přibližně jednou za půl roku. Vzory samotné se mezi minor verzemi nemění; mění se API kolem nich.

Kdo některý z bodů nesplňuje, knihu přesto přečte, jen u některých kapitol bude potřebovat víc soustředění. Obtížnost uvádí hlavička každé kapitoly. Nejvyšší stupeň má osm z nich, mimo jiné Návrh agregátu, Event Sourcing, Ságy, DDD a microservices a závěrečná případová studie.

P.02 Co kniha pokrývá#

Kniha se dělí na osm tematických částí a každá kapitola staví na předchozích. Webové rozcestníky seskupují tytéž kapitoly hruběji: Základy (kap. 1–5), Taktika (6–8), Architektura (9–11), Vzory (12–16), Praxe (17–22) a Syntéza (23–24). Hranice částí s nimi sedí, jen Praxe zahrnuje části 5 až 7.

Strategie stojí před taktikou záměrně. Evans na QCon London 2009 shrnul, co by ve své knize udělal jinak: stavební bloky přecenil, zatímco hranice kontextů a Core Domain měly přijít mnohem dřív. Uspořádání knihy z tohoto přehodnocení vychází.

Část 1 – Strategický design (kap. 1–5)

Strategický design rozhoduje, kde DDD vůbec nasadit. Pokrývá filozofii DDD, Ubiquitous Language, identifikaci subdomén (Core, Supporting, Generic), Bounded Context a Context Mapping. Doplňují ho dvě praktické techniky, bez kterých strategický design ve skutečné organizaci nefunguje: Event Storming Alberta Brandoliniho a Team Topologies (Skelton & Pais, 2019).

Zde se rozhoduje, jestli pokračovat. První signál dají kapitoly 1 a 2: jestli má váš projekt dost složitou doménu a kde leží jeho Core. Úplný rámec s rozhodovacím stromem obsahuje kapitola Kdy DDD nepoužívat. Než kvůli signálu „ne“ odložíte zbytek knihy, ověřte ho právě tam.

Část 2 – Taktický design (kap. 6–8)

Taktický design pokrývá konkrétní stavební bloky doménového modelu: entity, hodnotové objekty, agregáty, repozitáře, doménové služby, doménové události. Slovník k nim zavádějí Základní koncepty. Těžištěm taktické části je kapitola 7 o návrhu agregátu. Hranice agregátu je nejtěžší rozhodnutí v taktickém DDD a chyba v ní stojí násobně víc než chyba v jednotlivé třídě.

Taktickou část uzavírají doplňující taktické vzory (Specification Pattern, Factory, Module).

Část 3 – Architektura a implementace v Symfony (kap. 9–11)

Srovnání architektonických stylů (Layered, Hexagonal, Onion, Clean Architecture, Vertical Slice) určuje, kam modelovaný kód uložit. Následuje konkrétní mapování DDD do Symfony 8: adresářová struktura podle Bounded Contexts, vlastní Doctrine typy pro hodnotové objekty, Symfony Messenger jako Command/Query Bus, Dependency Injection a autowiring.

Kapitola 11 řeší autorizaci ve čtyřech vrstvách: Edge (firewall), Use Case (Voter), Aggregate (doménový invariant), Field (read model filtrace).

Část 4 – Pokročilé vzory a výkon (kap. 12–16)

CQRS (oddělení čtení a zápisu), Event Sourcing (stav jako sekvence událostí), Ságy a Process Managery (dlouho běžící procesy s kompenzací), Outbox Pattern (spolehlivé doručení událostí mimo kontext). Část uzavírá kapitola Read modely, projekce a výkon (N+1 problém, lazy loading, read modely, snapshoty, hot aggregates).

Tyto vzory se nehodí do každého projektu, a kapitoly proto rozebírají i to, kdy se nevyplatí.

Část 5 – Testování (kap. 17)

Testovací strategie: unit testy doménové vrstvy, integrační testy s Doctrine, architektonické testy s Deptrac.

Část 6 – Migrace a microservices (kap. 18–19)

Postupný přechod z CRUD architektury na DDD pomocí Strangler Fig Pattern. Vztah Bounded Context vs. microservice: kdy platí 1:1, kdy modulární monolit vychází lépe než distribuované služby a jak včas rozeznat distributed monolith.

Část 7 – Provozní problémy a anti-vzory (kap. 20–22)

Tři kapitoly se z různých úhlů dívají na to, co se v DDD pokazí. Kapitola 20 pokrývá konkrétní provozní třenice s Doctrine, Messengerem a Symfony Formem. Kapitola 21 je katalog kódových anti-vzorů (anémický model, Primitive Obsession, God Aggregate, sdílená databáze). Kapitola 22 odpovídá na otázku, kdy DDD vůbec nepoužívat.

Část 8 – Praktické příklady (kap. 23–24)

Tři krátké příklady (e-shop, blog, správa uživatelů) jako shrnující průřez. Závěrečná případová studie popisuje implementaci systému pro správu projektů krok za krokem, od doménové analýzy přes architekturu, agregáty a CQRS až po read modely s reconciliation.

Pozn.: Mimo hlavní řadu kapitol existuje na webu ještě DDD a umělá inteligence. Kapitola shrnuje, co o vztahu DDD a AI říkají Eric Evans, Martin Fowler, Kent Beck a další. V tištěné a EPUB verzi chybí, protože se téma rychle vyvíjí a web jde aktualizovat pružněji.

P.03 Jak číst tuto knihu#

Čtení od první do poslední kapitoly funguje, ale málokdo ho potřebuje. Většina čtenářů otevře knihu kvůli konkrétní bolesti. Pět doporučených cest podle role:

Pro junior/mid Symfony developera

Cíl: pochopit, co DDD je, a naučit se ho rozeznat v cizím kódu. Vlastní implementace přijde až s druhým a třetím projektem. Doporučené pořadí:

Volitelně po měsíci praxe: CQRS a Anti-vzory.

Pro senior PHP developera

Místo čtení od první kapitoly se vyplatí vstoupit do knihy u problému, který vás sem přivedl.

Souvislé čtení od kapitoly 1 do 24 se vyplatí, pokud DDD zavádíte poprvé na zelené louce. Průřez celou knihou v jednom příkladu nabízí Případová studie.

Pro architekta

Cesta vede přes strategii a celkový obraz: méně kódu, víc rozhodnutí.

Pro tech leada

Organizační pohled a praktické problémy. Cesta začíná u kapitoly Conway's Law a Team Topologies, tedy u otázky, jak týmovou strukturou ovlivnit architekturu. Navazuje Event Storming a Domain Storytelling s workshopem, který zavedete do týmu, a Migrace z CRUD na DDD s postupným přechodem bez zastavení vývoje. Realistická očekávání dodá DDD v praxi – kde to bolí. Zbývají dvě kapitoly: Anti-vzory jako přehled kódových signálů, které hledat při code review, a Kdy DDD nepoužívat pro chvíle, kdy je namístě říct ne.

Pro vývojáře migrujícího z CRUD

Konkrétní cesta, jak existující projekt postupně transformovat.

Další kapitoly pak podle konkrétní bolesti vaší aplikace.

P.04 Konvence v knize#

Následující konvence platí ve všech kapitolách.

Hlas a tón

Kniha vyká. Věty jsou krátké a každá říká jednu věc. Místo „mocný framework“ stojí v textu konkrétně, co Symfony Messenger umí a co ne. Osobní komentáře autora ani nadsázky v textu nejsou.

Styl kódu

Kód cílí na PHP 8.4 a Symfony 8 s Doctrine ORM 3. Které rysy jazyka příklady předpokládají, shrnuje sekce Předpoklady. Na starší verzi princip platí dál, jen syntaxe je jiná.

Atributy Doctrine (#[ORM\Entity]) stojí přímo na doménových třídách jako pragmatická výchozí volba. Striktní oddělení doménové vrstvy od ORM nabízí Persisted Object Pattern, tedy samostatná persistenční třída a mapper. Většina příkladů používá první variantu, protože je v Symfony projektech rozšířenější.

Ukázky navíc sdílejí jeden slovník, se kterým se poprvé potkáte v Základních konceptech:

  • Agregáty dědí z bázové třídy AggregateRoot s metodami record() a releaseEvents().
  • Doménové události nesou jména v minulém čase bez sufixu Event, tedy OrderPlaced, ne OrderPlacedEvent.
  • Hodnotové objekty vystavují public readonly vlastnosti, čtou se jako $email->value.
  • Identifikátory vznikají přes symfony/uid a Uuid::v7().
  • Agregáty se odkazují jen přes ID. Celá instance jednoho agregátu se nikdy nepředává do metody jiného.
  • Příkazy pro command bus se jmenují slovesnou frází bez sufixu (PlaceOrder, RegisterUser), jejich obsluha nese sufix Handler (PlaceOrderHandler).
  • Peníze a další sdílené hodnotové objekty žijí v App\SharedKernel\Domain, stejně jako AggregateRoot.

Průběžným příkladem je objednávka. Vzniká přes Order::place(), položky přijímá metodou addItem() a částky drží v hodnotovém objektu Money. Trojice Order, Money, Email se vrací kapitolu za kapitolou, takže ke každému vzoru nepřibývá nová doména.

Každý PHP blok v knize prochází kontrolou php -l v CI. Ukázky jsou tedy syntakticky platné, ale zůstávají ilustrací vzoru. Před nasazením je potřeba je přizpůsobit vlastní doméně.

Prvky stránky

Hlavička kapitoly uvádí odhadovanou dobu čtení a obtížnost na škále 1 až 4. Text končí blokem častých otázek, někde následuje ještě sekce se zdroji a další četbou. Celou knihou pak provázejí dvě navigační stránky: Cheat Sheet a Glosář.

Callouty

Kniha používá čtyři typy callout boxů. Modrý note přidává kontext nebo odkaz na hlubší zdroj. Zelený pattern doporučuje vzor s konkrétním kódem, oranžový warn upozorňuje na riziko nebo častou chybu. Červený anti označuje anti-vzor.

Diagramy

Diagramy vznikají z PlantUML zdrojů a do textu se vkládají jako SVG. Zdroje .puml jsou v repozitáři knihy.

Vnitřní odkazy

Vnitřní odkazy mezi kapitolami používají cesty (/co-je-ddd, /zakladni-koncepty), ne čísla kapitol. Přečíslování tak odkazy nezneplatní. Externí odkazy na knihy a články používají plný URL.

Citace

Knihy a referenční články text cituje přímo v místě použití (např. „Vernon, Implementing DDD, kap. 8“), u řady kapitol pak souhrnně v závěrečné sekci s další četbou. Hlavní zdroje, na které kniha staví:

  • Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software (Addison-Wesley, 2003).
  • Vaughn Vernon, Implementing Domain-Driven Design (Addison-Wesley, 2013) a Domain-Driven Design Distilled (2016).
  • Vlad Khononov, Learning Domain-Driven Design (O'Reilly, 2021).
  • Sam Newman, Building Microservices, 2nd ed. (O'Reilly, 2021).
  • Chris Richardson, Microservices Patterns (Manning, 2018).
  • Matthew Skelton & Manuel Pais, Team Topologies (IT Revolution, 2019; druhé vydání 2025).
  • Martin Fowler, Patterns of Enterprise Application Architecture (Addison-Wesley, 2002).

P.05 Co dál#

Pokud jste tu poprvé, otevřete kapitolu Co je Domain-Driven Design. Po ní byste měli mít jasno, jestli pokračovat. Rozhodovací rámec pro opačný závěr nabízí kapitola Kdy DDD nepoužívat.

Pokud DDD už znáte a hledáte konkrétní téma, projděte si Cheat Sheet, jednostránkový přehled vzorů s odkazy na příslušné kapitoly. Pro definice termínů slouží Glosář.

Kniha je živý dokument. Aktuální verzi textu najdete vždy na ddd-v-symfony.katuscak.cz, kontakt pro opravy a připomínky je na stránce O autorovi.

Časté otázky

Musím knihu číst lineárně od první kapitoly?

Ne. Pořadí kapitol je stavěné tak, aby každá navazovala na předchozí, ale většina čtenářů přichází s konkrétním problémem. Sekce Jak číst tuto knihu nabízí pět cest podle role: junior/mid Symfony developer, senior PHP developer, architekt, tech lead a vývojář migrující z CRUD. Souvislé čtení od kapitoly 1 do 24 se vyplatí hlavně tehdy, když DDD zavádíte poprvé na novém projektu.

Musím před touto knihou přečíst Evanse nebo Vernona?

Ne. Kniha nepředpokládá žádnou předchozí znalost DDD, jen zkušenost s PHP, Symfony a objektovým programováním. Evans (2003), Vernon (2013) a Khononov (2021) zůstávají zdrojem hlubšího teoretického základu a odkazy na konkrétní pasáže jsou přímo v textu kapitol. Přehled titulů shrnuje sekce Citace a stránka Zdroje.

Spustím ukázky na Symfony 6 nebo 7?

Ukázky cílí na PHP 8.4, Symfony 8 a Doctrine ORM 3, jak popisuje sekce Předpoklady. Na starším stacku část syntaxe nefunguje, například asymetrická viditelnost public private(set) vyžaduje PHP 8.4. Vzory samotné na verzi frameworku nezávisejí, takže princip zůstává platný a mění se jen zápis.

Můžu kód z knihy použít ve svém projektu?

Ukázky jsou psané tak, aby šly převzít, a každý PHP blok prochází kontrolou php -l v CI. Zůstávají ale ilustrací vzoru, ne hotovým řešením. Hranice agregátů, jména událostí i struktura kontextů se odvozují od konkrétní domény, takže kopie bez úprav obvykle přenese cizí model do cizího projektu.