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

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 fine-tunoval LLM na ubiquitous language jednoho bounded contextu - na terminologii, pravidla a výrazy, které tým denně používal v diskuzí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."

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. Argument je jednoduchý: čím precizněji definujeme pojmy a vztahy v ubiquitous language, tím menší je prostor pro ambiguitu v promptu, tím předvídatelnější jsou výstupy modelu. Precizní jazyk redukuje entropii na vstupu a tím i rozptyl na výstupu.

Protiváhu k tomuto nadšení tvoří 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 - a že preferovaný formát AI je 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 elegantní myšlenka pro komplexní enterprise systémy, ale pro většinu webových aplikací je konvence nad konfigurací - prostá angličtina nebo čeština v komentářích a názvech - dostatečně výmluvná.

Klíčový kontext: 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. To z ní dělá přirozený most mezi doménovými experty a LLM: pojmy, které jsou jasné lidem, jsou jasné i modelu. Otázka zní, zda náklady na vybudování a udržení ubiquitous language jsou proporcionální k výhodám - a odpověď se liší projekt od projektu.

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 reverse engineeringu softwarové architektury - automatickému mapování end-to-end toků, závislostí a hranic v existující codebase. 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ý context má svůj kontext (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 rovněž poukazuje na zajímavý fenomén: moderní 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.

Protiváhu tvoří data z GitClear z roku 2024, analyzovaná Visual Studio Magazine. Podle tohoto výzkumu se code churn - podíl řádků přepsaných nebo smazaných do dvou týdnů od vytvoření - u AI generovaného kódu v roce 2024 přibližně zdvojnásobil oproti pre-AI stavu z roku 2021. GitClear hovoří o kódu, který je „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í, ale větší architektonické vzory - jako jsou hranice mezi moduly, zachování invariantů nebo konzistentní pojmenovávání napříč codebase - jsou porušeny. Bounded contexts jsou právě odpovědí na tento problém, ale je otázka, zda samotná existence bounded contextu stačí, nebo zda AI agent potřebuje explicitní instruktáž o každém pravidle uvnitř kontextu.

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 - kdy vývojář používá AI jako asistenta a zachovává zodpovědnost za rozhodnutí - a vibe coding - kdy 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."

Beckův argument je, že testy jsou jediným mechanismem, který AI nemůže zfalšovat. Pokud AI generuje kód a existuje sada testů, která specifikuje chování z pohledu domény - nikoli implementační detaily, ale doménová pravidla - pak je selhání testu objektivním signálem, že AI se odchýlila od záměru. TDD tak ve spolupráci s AI plní roli, která v tradičním vývoji náleží code review: průběžná verifikace toho, zda kód dělá to, co má. Beck přiznává, že sám testuje méně věcí než dříve, ale testy, které píše, jsou úmyslnější - zaměřené na doménová pravidla a hraniční případy, nikoli na happy path.

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ž output 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."

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í.

Protiváhou k tomuto techno-optimismu je DHH, jehož vyjádření jsou záměrně provokativní. V sérii blogpostů 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 varuje před nebezpečím, kdy vývojář přestane rozumět kódu, který provozuje - stane se project managerem AI místo inženýrem. Tento argument není anti-AI - DHH AI používá - ale je to 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 robustnější než testování implementačních detailů.

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, která jsou absolutní, nemění se a jejichž porušení má závažné důsledky - například to, ž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 dramatické. 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í, ale aby tyto opravy procházely 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. Toto rozlišení není historická nehoda - je to záměrné rozhodnutí přiřadit komplexitu tam, kde leží doménová komplexita. S příchodem AI toto rozhodnutí nabývá nové dimenze: 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 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. Klíčová 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 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?

Architektonické nástroje a kontext pro AI

Jedním z nejzajímavějších trendů posledních dvou let je konvergence AI nástrojů 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, která je nápadně podobná 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í: píší Cursor rules a CLAUDE.md 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á, jak generativní AI může částečně automatizovat tvorbu doménových metamodelů v DDD - konkrétně generování doménově specifických JSON objektů. Výsledky jsou předběžné, ale naznačují, že strukturovaný, explicitní kontext vede k lepším výsledkům než nestrukturovaný nebo implicitní.

ThoughtWorks Technology Radar vol. 33 (listopad 2025) sice přímo nezmiňuje DDD v kontextu AI, ale obsahuje několik relevantních blipů: „Using GenAI to understand legacy codebases" v kategorii Adopt, „Context engineering" v kategorii Assess a „Anchoring coding agents to a reference application" rovněž v Assess. Tyto techniky sdílejí společný princip: čím přesnější kontext AI dostane, tím lepší jsou její výstupy - princip, který je DDD bounded contextům vlastní.

Protiváha je důležitá: tyto nástroje fungují i bez DDD. Jednoduchý kód s jasnými konvencemi - convention over configuration v Rails stylu - může být 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ý blogpost „DHH Is Wrong" a série na toto téma ilustrují, že konvence může být stejně výkonná jako explicitní modelování - otázka je, co se stane, když projekt vyroste za hranice, kde konvence stačí.

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 % production-ready kód s bounded contexts zní dobře, ale co těch 12 %? A kde selhávají - v edge cases, v porušení invariantů, v chybném pojmenování? Odpověď na tuto otázku rozhoduje o tom, zda bounded contexts jsou dostatečnou zárukou, nebo zda je potřeba dodatečná vrstva verifikace - například 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é workflow (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í: mikroslužby 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ý junioři nerozumí, jak se budují doménové znalosti pro příští generaci?

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ě optimistické a zdůrazňují potřebu nových nástrojů a metrik. Brandolini zachovává lidský prvek v centru.

DHH tvoří důležitou protiváhu: připomíná, že velká část softwarového průmyslu je stále CRUD, že jednoduchost má svou hodnotu a že AI může být výkonná i bez formálního doménového modelování. Tato pozice není špatná - je to připomínka, že DDD není odpověď na každou otázku.

Konvergence, kterou vidíme v roce 2026, je tato: 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. Není to jediná cesta - konvence, dobré testy a čistý kód mohou dosáhnout podobného efektu - ale je to vyzkoušená a dobře zdokumentovaná cesta.

Klíčové je rozhodovat se na základě 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? Tyto otázky - ne přítomnost nebo nepřítomnost AI v toolchainu - by měly řídit architektonické rozhodnutí.

Zdroje a další čtení