Podrobný průvodce · česky
Domain-Driven Design v Symfony 8
Od základních konceptů přes CQRS a Event Sourcing až po reálné případové studie. Vše s ukázkami kódu v PHP 8.4+ a Symfony 8.
Začít s DDD →Jak číst průvodce
Pro začátečníky
Začínám s DDD
Pro pokročilé
Znám základy
Témata průvodce
Co je Domain-Driven Design?
Základní filozofie DDD, Ubiquitous Language a Bounded Context.
Základní koncepty DDD
Entity, Value Objects, Agregáty, Repozitáře a Doménové události.
CQRS v Symfony 8
Oddělení operací čtení a zápisu pomocí Messenger komponenty.
Event Sourcing
Uchování stavu aplikace jako sekvence doménových událostí.
DDD v praxi – kde to bolí
20 reálných problémů: Doctrine, Messenger, validace, ACL, strangler fig a přesvědčení managementu.
Kdy DDD nepoužívat
7 konkrétních situací, kdy DDD přinese víc škody než užitku - s alternativami pro každý případ.
DDD a umělá inteligence
Co říkají Eric Evans, Martin Fowler, Kent Beck a DHH o vztahu DDD a AI nástrojů.
Implementace v Symfony 8
Praktická implementace DDD architektury ve Symfony projektu.
Případová studie
Kompletní e-shop implementovaný v DDD architektuře krok za krokem.
Glosář DDD terminologie
Přehled všech hlavních pojmů DDD s vysvětlením v češtině.
Časté otázky
Kolik času a lidí zavedení DDD v projektu vyžaduje?
Pilotní Bounded Context zpravidla doručí první výsledky za 3–6 měsíců, plná migrace středně velké aplikace má realistický horizont 12–24 měsíců. Velikost týmu není rozhodující – podstatnější je přístup k doménovému expertovi a čas vývojářů na osvojení strategických a taktických vzorů. Strangler Fig Pattern umožňuje nasazovat DDD po částech vedle původní CRUD architektury bez nutnosti zastavit vývoj nových feature. Podrobnosti v kapitole Migrace z CRUD na DDD.
Kdy DDD použít a kdy ne?
DDD se vyplatí v projektech s bohatou doménou, dlouhým horizontem a přístupem k doménovým expertům – typicky v bankovnictví, pojišťovnictví, logistice nebo regulovaných odvětvích. Nevhodné je pro prosté CRUD aplikace, prototypy a situace, kdy tým nemá čas si DDD osvojit. Detailní rozbor v kapitole Kdy DDD nepoužívat.
Potřebuji pro DDD doménového experta?
Ano, přístup k doménovému expertovi je jedním z předpokladů úspěchu. Bez něj tým nemá zdroj pro Ubiquitous Language a model se rychle rozchází s realitou. Expertem nemusí být externí konzultant – bývá to produktový manažer, zkušený uživatel nebo regulovaný subjekt. Bez tohoto přístupu se DDD zpravidla redukuje na prázdné taktické vzory bez doménové hodnoty. Viz Kdy DDD nepoužívat.
Jak začít s DDD v Symfony projektu?
Přirozená posloupnost je: nastudovat základní pojmy, vytipovat Bounded Context, definovat Ubiquitous Language, navrhnout agregáty s jasnými invarianty a zavést repozitáře a aplikační služby nad Symfony Messengerem. U existujícího projektu pomáhá Event Storming pro analýzu domény. Startovacím bodem je kapitola Implementace DDD v Symfony.
V čem se DDD liší od klasického CRUD?
CRUD architektura mapuje formuláře na databázové tabulky – logika obvykle žije v kontrolerech a „Service" třídách, model je pasivní. DDD naopak soustředí logiku do doménových objektů (agregátů), které vynucují invarianty a komunikují přes definované rozhraní. CRUD je levnější na start, DDD se vyplatí s rostoucí komplexitou domény. Srovnání v kapitole Migrace z CRUD na DDD.
O autorovi
