DDD a umělá inteligence – co říkají autority

ai.01 Ubiquitous language jako rozhraní pro LLM

Jedním z nejkonkrétnějších výroků o vztahu DDD a AI pochází přímo od Erica Evanse. Na konferenci Explore DDD 2024 Evans popisoval experiment, ve kterém tým doladil (fine-tuning) LLM na ubiquitous language jednoho bounded contextu. Šlo o terminologii, pravidla a výrazy, které tým denně používal v diskusích s doménovými experty. Výsledek byl podle Evanse překvapivě přesvědčivý: specializovaný model byl levnější v provozu i přesnější než univerzální model, který musel doménu vyvozovat z kontextu v promptu.

„Because some parts of a complex system never fit into structured parts of domain models, we throw those over to humans to handle. Maybe we'll have some hard-coded, some human-handled, and a third, LLM-supported category.“

– Eric Evans, Explore DDD 2024 (via InfoQ)

Evans dále navrhl, že několik fine-tuned modelů, každý určený pro jiný účel, představuje silné oddělení zodpovědností – a že vytrénovaný jazykový model lze chápat jako bounded context. V téže přednášce předpověděl, že NLP úlohy – klasifikace záměrů, extrakce entit, shrnutí dokumentů – se stanou plnohodnotnými subdoménami v DDD modelu. Stejně jako dnes máme samostatné bounded contexty pro platby, notifikace nebo inventory, budeme mít bounded context pro „rozumění textu“ nebo „extrakci strukturovaných dat“. Tato předpověď rezonuje s tím, jak velké firmy dnes budují AI platformy – jako interní služby se svými API hranicemi, nikoli jako průřezovou vrstvou přes celý systém.

Martin Fowler na toto téma navazuje z jiného úhlu. Ve svých poznámkách o přípravě na nedeterministické výpočty zmiňuje DSL a doménově specifický jazyk jako nástroj pro rigorózní promptování LLM. Logika za tím: precizně definované pojmy a vztahy v ubiquitous language zužují prostor pro ambiguitu v promptu, a tím i rozptyl výstupů modelu. Pevný jazyk na vstupu znamená méně entropie na výstupu.

Opačný pól drží David Heinemeier Hansson (DHH). Na konferenci Rails World 2025 a v rozhovorech pro The New Stack DHH argumentoval, že Ruby je dostatečně čitelné na to, aby LLM chápal kód bez speciální terminologie. Preferovaným formátem pro AI je podle něj Markdown, nikoli doménový jazyk definovaný formálními pravidly. DHH poukazuje na to, že Rails 8.1 přidal nativní Markdown rendering právě proto, že to je formát, ve kterém AI přirozeně komunikuje. Z jeho pohledu je ubiquitous language užitečná myšlenka pro komplexní enterprise systémy. Pro většinu webových aplikací je ale konvence nad konfigurací – prostá angličtina nebo čeština v komentářích a názvech – dostatečně výmluvná.

Velké jazykové modely pracují s přirozeným jazykem jako svým primárním médiem. Ubiquitous language v DDD je precizní podmnožina přirozeného jazyka – terminologie domény zbavená nejednoznačností a obohacená o doménová pravidla. Funguje proto jako most mezi doménovými experty a LLM: pojmy srozumitelné lidem jsou srozumitelné i modelu. Otázka zní, zda náklady na vybudování a udržení ubiquitous language odpovídají získaným výhodám – a odpověď se liší projekt od projektu. Definici a roli ubiquitous language v DDD popisuje kapitola Základní koncepty DDD.

ai.02 Bounded contexts a kvalita generovaného kódu

Existují data. Ne rozsáhlé akademické studie s tisíci vzorků, ale praktické měření z reálných projektů, která začínají ukazovat konzistentní obraz. Přehled dostupných zdrojů – od příspěvků praktiků přes konferenční záznamy po preprint na arXiv – naznačuje, že hranice bounded contextu mají měřitelný dopad na kvalitu kódu generovaného LLM.

Nick Tune je jedním z nejvíce aktivních praktiků na průsečíku DDD a AI. V článku pro O'Reilly Radar (2026) popisuje, jak použil Claude Code k reverznímu inženýrství softwarové architektury – automatickému mapování end-to-end toků, závislostí a hranic v existující kódové bázi. V návazném článku pak ukazuje, jak lze pomocí knihovny ts-morph deterministicky extrahovat architektonické vzory, které slouží jako vstup pro AI agenty. Tune vidí DDD bounded contexts jako přirozený rámec pro tento přístup – každý kontext má svůj rámec (ve smyslu CLAUDE.md nebo Cursor rules), svou terminologii a své invarianty. AI agent pracující uvnitř jednoho bounded contextu potřebuje znát méně – a tím dělá méně chyb.

Tune také poukazuje na zajímavý fenomén: dnešní AI nástroje si de facto vybudovaly vlastní verzi bounded contextu na úrovni konfigurace. Cursor používá soubory .cursor/rules/*.mdc, GitHub Copilot má .github/copilot-instructions.md, Claude Code používá CLAUDE.md. Každý z těchto souborů definuje pravidla, terminologii a omezení pro konkrétní kontext – přesně to, co DDD nazývá bounded context s ubiquitous language. Tím, že vývojáři tyto soubory píší, provádějí implicitně DDD modelování, aniž by to tak nutně nazývali.

Druhý pohled přinášejí data z GitClear z roku 2024, analyzovaná Visual Studio Magazine. Code churn je podíl řádků přepsaných nebo smazaných do dvou týdnů od vytvoření. Podle tohoto výzkumu se u AI generovaného kódu v roce 2024 přibližně zdvojnásobil oproti stavu z roku 2021, před nástupem AI. GitClear popisuje výsledek jako kód „lokálně koherentní, ale architektonicky nekonzistentní“. Každý soubor nebo funkce může být syntakticky správná a pro svůj bezprostřední účel funkční. Větší architektonické vzory – hranice mezi moduly, zachování invariantů nebo konzistentní pojmenování napříč kódovou bází – ale drhnou. Bounded contexts řeší přesně tento problém. Otevřená zůstává otázka, zda samotná existence bounded contextu stačí, nebo zda AI agent potřebuje explicitní instruktáž o každém pravidle uvnitř kontextu.

ai.03 Testování jako kontrolní mechanismus pro AI

Kent Beck – autor TDD, autor Extreme Programming – se od začátku roku 2024 intenzivně věnuje otázce, jak AI mění způsob programování. Podle shrnutí v The Pragmatic Engineer je TDD při práci s AI agenty obzvlášť cenné. Beck rozlišuje mezi dvěma módy. Augmented coding znamená, že vývojář používá AI jako asistenta a zachovává zodpovědnost za rozhodnutí. Vibe coding znamená, že vývojář přijímá vše, co AI vygeneruje, bez porozumění a bez verifikace.

„In vibe coding you don't care about the code, just the behavior of the system. In augmented coding you care about the code, its complexity, the tests, & their coverage.“

– Kent Beck, Augmented Coding: Beyond the Vibes (Substack, 2024)

Beckův argument zní: testy jsou jediným mechanismem, který AI nemůže zfalšovat. Předpokládejme, že AI generuje kód a existuje sada testů specifikující chování z pohledu domény – ne implementační detaily, ale doménová pravidla. Selhání testu je pak objektivním signálem, že AI se odchýlila od záměru. TDD ve spolupráci s AI přebírá roli code review – průběžnou verifikaci toho, zda kód dělá, co má. Beck přiznává, že sám testuje méně věcí než dříve. Testy, které píše, jsou ale úmyslnější – zaměřené na doménová pravidla a hraniční případy, nikoli na hlavní scénář.

Martin Fowler přichází s podobným, ale méně optimistickým rámcem. V rozhovoru pro The New Stack Fowler přirovnává AI k „pochybnému kolegovi“ – kolaborátorovi, jehož výstup je třeba pečlivě revidovat, nikoli slepě přijímat.

„You've got to treat every slice as a PR from a rather dodgy collaborator who's very productive in the lines-of-code sense of productivity, but you know you can't trust a thing that they're doing.“

– Martin Fowler, The New Stack, 2024

Fowler zdůrazňuje, že nedeterminismus LLM – stejná otázka, jiný výsledek – od základu mění způsob, jakým přemýšlíme o testování. Tradiční testování předpokládá deterministický systém: stejný vstup, stejný výstup, vždy. Pro AI komponenty to neplatí. Fowler volá po nových metrikách a nových přístupech, ale přiznává, že komunita je teprve na začátku tohoto hledání.

Třetí hlas patří DHH a jeho vyjádření jsou záměrně provokativní. V sérii článků a přednášek DHH popisuje vlastní zkušenost s intenzivním používáním AI asistentů a vyvozuje z ní znepokojivý závěr:

„I can literally feel competence draining out of my fingers!“

– DHH, The New Stack, 2025

DHH varuje před nebezpečím, kdy vývojář přestane rozumět kódu, který provozuje – stane se manažerem projektu AI místo inženýrem. Sám DHH přitom AI používá. Jde mu o varování, že nekritické přijetí AI výstupu degraduje schopnost rozpoznat, kdy AI dělá chybu. Bez doménového porozumění nejsou testy dostatečné: vývojář, který nechápe doménu, nepíše správné testy, a AI pak plní testy generováním falešně pozitivního kódu.

Kontext pro DDD komunitu: TDD a code review nejsou specifické pro DDD, ale DDD komunita je s nimi historicky propojena. Taktické DDD vzory – agregáty s invarianty, doménové události jako přirozené kontrakty – jsou přirozeně testovatelné na úrovni domény. Agregát definuje pravidlo; test verifikuje pravidlo; AI generuje implementaci; test signalizuje odchylku. Tento cyklus je odolnější než testování implementačních detailů. Konkrétní strategie testování DDD modelů – unit testy agregátů, integrační testy přes Messenger, contract testy mezi kontexty – popisuje kapitola Testování DDD.

ai.04 AI v doménové komplexitě vs. CRUD

Evans ve své Explore DDD 2024 přednášce navrhl novou taxonomii softwarových rozhodnutí – tři kategorie, které rozšiřují tradiční DDD rozlišení o AI vrstvu. První kategorie jsou hard-coded decisions: pravidla absolutní, neměnná a se závažnými důsledky při porušení. Příkladem je požadavek, že záporný stav účtu musí projít explicitním schválením. Druhá kategorie jsou human-handled decisions: situace tak komplexní nebo citlivé, že musí rozhodovat člověk. Třetí, nová kategorie jsou LLM-supported decisions: situace, kde přesnost 80–90 % je přijatelná, kde rozhodnutí lze revidovat a kde náklady na chybu jsou nízké.

Tato taxonomie má přímý dopad na to, kde AI dává smysl a kde ne. Ve vysoce komplexní doméně – pojišťovnictví, bankovnictví, zdravotnictví – je podíl hard-coded decisions vysoký a náklady na chybu vysoké. Paradoxně to jsou domény, kde DDD přináší největší hodnotu, ale kde je AI nejnebezpečnější, pokud není správně ohraničena. LLM-supported decisions existují i zde – například kategorizace dokumentů nebo návrh odpovědi zákaznickému servisu – ale musí být jasně odděleny od hard-coded logiky.

Vaughn Vernon přidává konkrétní technický vzor: LLM jako „fix suggester“. Vernon navrhuje, aby LLM v produkčním systému navrhoval opravy pro selhání. Tyto opravy musí projít verifikací – ať už automatizovanou nebo lidskou – před aplikací. Hovoří o konceptu self-healing software: systém, který detekuje anomálie, požádá LLM o návrh opravy, verifikuje ji testy a teprve pak ji aplikuje. DDD bounded context v tomto scénáři definuje pravidla verifikace: co smí LLM změnit a co musí zůstat neměnné.

Referenční implementace Microsoftu – eShopOnContainers – ilustruje toto rozlišení na praktickém příkladu. Modul Ordering používá plné taktické DDD: agregáty, doménové události, CQRS. Modul Catalog je prostý CRUD s Entity Framework. Rozdělení vzniklo záměrně, ne historickou nehodou: implementační komplexita patří tam, kde leží komplexita doménová. S příchodem AI se k této úvaze přidává nová otázka: kde leží hranice mezi tím, co AI může autonomně rozhodovat, a kde musí platit explicitní doménová pravidla?

DHH nabízí radikální protiváhu:

„A lot of people, I think, are very uncomfortable with the fact that they are essentially crud monkeys. They just make systems that create, read, update, or delete rows in a database and they have to compensate for that existential dread by over-complicating things.“

– DHH, Lex Fridman Podcast

DHH otevřeně říká, že většina vývojářské práce je „CRUD monkeying“ – psaní aplikací, které přijímají data, ukládají je a zobrazují. Pro tuto kategorii aplikací je DDD přeceňované – a AI, která generuje CRUD kód z jednoduchého popisu, je přirozeným řešením bez potřeby doménového modelu. Hlavní otázka, na kterou DHH odpovídá jinak než Evans, je: jak velký podíl softwarového průmyslu tvoří skutečně komplexní domény versus CRUD monkeying? A mění AI tuto hranici? Buď tím, že CRUD kód zlevní natolik, že zbyde čas na komplexní doménu, nebo tím, že komplexní doménové problémy de facto „zjednoduší“ na LLM-supported decisions. Pro praktické rozhraničení toho, kdy DDD nasazovat a kdy ne, viz kapitolu Kdy DDD nepoužívat.

ai.05 Architektonické nástroje a kontext pro AI

AI nástroje za poslední dva roky konvergovaly k de facto implementaci DDD konceptů na úrovni konfigurace. Cursor IDE používá soubory v adresáři .cursor/rules/ s příponou .mdc: každý soubor definuje pravidla pro konkrétní část projektu, terminologii a omezení. GitHub Copilot přidal podporu pro .github/copilot-instructions.md: globální instrukce pro všechny konverzace v daném repozitáři. Claude Code používá CLAUDE.md na úrovni projektu i adresáře – přesně tato stránka, na které čtete tento článek, se řídí CLAUDE.md v kořenovém adresáři repozitáře.

Všechny tyto soubory sdílejí strukturu nápadně podobnou tomu, co DDD nazývá bounded context s ubiquitous language. Definují terminologii (jak se jmenují věci v projektu), pravidla (co smí a nesmí), kontext (co AI ví o projektu) a omezení (co AI dělat nebude). Nick Tune a další DDD praktici tuto paralelu aktivně využívají. Cursor rules a CLAUDE.md píší jako explicitní bounded context dokumenty, čímž propojují formální DDD terminologii s praktickými AI nástroji.

Akademický výzkum tuto praxi začíná zkoumat systematicky. Preprint na arXiv z roku 2026 (Wiegand et al.) zkoumá automatizaci tvorby doménových metamodelů v DDD pomocí generativní AI – konkrétně generování doménově specifických JSON objektů. Předběžné výsledky ukazují, že explicitní strukturovaný kontext vede k přesnějším výstupům než nestrukturovaný nebo implicitní.

ThoughtWorks Technology Radar vol. 33 (duben 2025) sice přímo nezmiňuje DDD v kontextu AI, ale obsahuje několik relevantních blipů. V kategorii Adopt je „Using GenAI to understand legacy codebases“. V kategorii Assess je „Context engineering“ a „Anchoring coding agents to a reference application“. Všechny tyto techniky stojí na stejném principu: přesnější kontext znamená přesnější výstupy AI – a přesně toto DDD bounded contexty zajišťují.

Druhá strana mince: ty samé nástroje fungují i bez DDD. Konzistentně psaný kód s jasnými konvencemi – convention over configuration v Rails stylu – bývá pro AI stejně čitelný jako explicitně modelovaný bounded context. Pokud projekt dodržuje konzistentní pojmenování, má dobré testy a je dobře rozčleněn do adresářů, AI agent se v něm orientuje i bez formálního DDD modelu. Proslulý článek „DHH Is Wrong“ a série na toto téma ukazují, že konvence dovede být stejně účinná jako explicitní modelování. Otevřená zůstává otázka, co se stane, když projekt vyroste za hranice, kde konvence stačí.

ai.06 Otevřené otázky a limity

Martin Fowler opakovaně zdůrazňuje, že oblast AI a softwarové architektury je v roce 2026 teprve na začátku. Nedeterminismus LLM – stejný prompt, jiný výstup – zatím nemá uspokojivou metriku. Jak měříme architektonickou konzistenci generovaného kódu? Jak verifikujeme, že AI respektuje hranice bounded contextu, když každé volání API může vrátit jiný výsledek? Fowler hovoří o tom, že „stále se učíme“ – a to je poctivý popis stavu oboru.

V datech zmíněných výše: 88 % produkčně použitelného kódu s bounded contexts zní dobře, ale co těch 12 %? A kde selhávají – v okrajových případech, v porušení invariantů, v chybném pojmenování? Odpověď rozhoduje, zda bounded contexts jsou dostatečnou zárukou. Případnou dodatečnou vrstvu verifikace mohou tvořit architektonické testy (ArchUnit, deptrac) nebo explicitní bounded context registry.

Alberto Brandolini – autor EventStorming – se k propojení AI a doménového modelování veřejně vyjadřuje zdrženlivě. Vzdělávací firma Avanscoperta, kterou spoluzaložil, nabízí workshopy zaměřené na AI-augmentované vývojové postupy (např. „The Agentic Developer Workshop“), ale ty nejsou přímo zaměřené na kombinaci DDD a AI. EventStorming zůstává v Brandoliniho pojetí fundamentálně lidskou aktivitou – sdílené pochopení domény se buduje v konverzaci, nikoliv v promptu.

Sam Newman – autor Building Microservices – se k AI zatím jasně nevyjádřil v kontextu DDD. Jeho pozice k distribuovaným systémům je dlouhodobě konzervativní: mikroservisy jako poslední možnost, nikoli jako výchozí architektura. Tato konzervativní pozice pravděpodobně platí i pro AI: nasadit LLM do produkčního systému je distribuovaná závislost se všemi problémy distribuovaných systémů – latencí, spolehlivostí, verzováním, monitoringem.

Otevřené otázky, na které obor zatím nemá odpověď:

• Mění AI hranici, kde DDD dává smysl? Pokud AI zlevní generování CRUD kódu natolik, že vývojáři mají více kapacity na komplexní logiku, může rozšířit množinu projektů, kde se DDD investice vyplatí.
• Stane se ubiquitous language standardem pro AI kontexty? Cursor rules a CLAUDE.md jsou ad hoc řešení. Mohla by DDD komunita přispět formálnější strukturou pro definici AI kontextů?
• Jaká bude role architekta v AI-augmentovaném týmu? Pokud AI generuje implementaci, architekt se stává primárně autorem kontextů, pravidel a verifikačních mechanismů – což je blíže k DDD modelování než k psaní kódu.
• Co se stane s juniorními vývojáři? DDD předpokládá, že tým rozumí doméně. Pokud AI generuje kód, kterému junioři nerozumí, jak se budují doménové znalosti pro příští generaci?

ai.07 Závěr

Syntéza pozic autorit vede k opatrnému, ale celkem konzistentnímu závěru: většina předních myslitelů v oblasti softwarového inženýrství vidí potenciální synergii mezi DDD principy a praktickým využitím AI. Evans a Tune jsou nejkonkrétnější – sdílejí praktické vzory a data. Fowler a Beck jsou opatrně optimističtí a zdůrazňují potřebu nových nástrojů a metrik. Brandolini zachovává lidský prvek v centru.

DHH tvoří důležitý opačný hlas: připomíná, že velká část softwarového průmyslu je stále CRUD, že jednoduchost má svou hodnotu a že AI dovede být účinná i bez formálního doménového modelování. Pozice není v rozporu s DDD – je to připomínka, že DDD nemá odpověď na každou otázku.

Konvergence roku 2026 stojí na jediné věci: struktura pomáhá. Ať už jde o DDD bounded contexts, Cursor rules nebo CLAUDE.md – explicitní, sdílený kontext zlepšuje výsledky AI. DDD přináší bohatou tradici myšlení o tom, jak takový kontext definovat. Existují i další cesty – konvence, dobré testy a čistý kód zvládnou podobný efekt – ale DDD je cesta vyzkoušená a dobře zdokumentovaná.

Rozhodovat se má smysl podle domény, týmu a projektu. Kde leží doménová komplexita? Kde jsou náklady na chybu vysoké? Kde bude systém žít pět let? Architektonické rozhodnutí by mělo vyplývat z těchto otázek, ne z přítomnosti nebo nepřítomnosti AI v toolchainu.

ai.08 Zdroje a další čtení