At DDD Europe in June, Martin Fowler wrote in his fragments that he suspects Domain-Driven Design "is going to be one of those things that will continue to be useful, indeed may become even more important," and he named Eric Evans's opening keynote the highlight of the conference. Evans framed that talk as a question, whether AI will amplify DDD or replace it, and offered a working hypothesis that domain models, bounded contexts, and language still matter even though the models will look different. His abstract left coding agents out on purpose, "where others have more interesting things to say," and the people who have taken that part up are the subject of this post.
What domain-driven design asks of a team
Evans's 2003 book makes two commitments that carry over to agents. The first is a ubiquitous language, which Fowler describes as a common, rigorous language between developers and users, built on the domain model the software uses and rigorous because "software doesn't cope well with ambiguity." The second is the bounded context, which starts from Evans's observation that "total unification of the domain model for a large system will not be feasible or cost-effective," as Fowler quotes him. A large system splits into contexts that each hold one consistent model, and a word like customer or product may mean something different inside each of them, with an explicit mapping where they meet.
Why agents raise the cost of an ambiguous word
Dennis Traub argues that agents change how ambiguity behaves. On a human team a vague term meets friction in review, in pairing, and in the question asked over coffee, whereas an agent writes code that compiles and tests that pass while the mismatch waits for a downstream system to read the same word differently. The agent also starts every session without any memory of the last disambiguation, so a term you settled on Monday has to be settled again on Tuesday unless it is written down. Russ Miles opens Domain Driven Agent Design with a finance assistant that treated a booking, which means revenue recognition in one context, and a reservation, which means risk allocation in another, as the same thing, and it "began taking action that would've landed the CFO in handcuffs." Daniel Schleicher states the stakes more plainly: the greatest leverage with AI lies "not in accelerating typing, but in establishing semantic agreement before implementation begins."
Matt Pocock arrives at the same place from the cost side. In the README of his skills repository he writes that agents are "dropped into a project and asked to figure out the jargon as they go," and that "they use 20 words where 1 will do." His before and after comes from a course tool he built: "There's a problem when a lesson inside a section of a course is made 'real' (i.e. given a spot in the file system)" becomes "There's a problem with the materialization cascade." In Software Fundamentals Matter More Than Ever he reports that reading the model's thinking traces showed a shared vocabulary improving the planning and letting the model think less verbosely, and he adds that he is still "on the edge of exploring" DDD, so the evidence is his reading of traces and not a measurement.
What an experiment measured
The closest thing to a measurement I found is a semantic erosion experiment published on GitHub, which tracks how many domain terms survive when an agent refactors a Java codebase for ten iterations. The subject is a synthetic royalty-collection system with six domain terms already in the code and four more that refactoring should surface. Neutral prompts such as "Refactor this project to improve readability" eroded nothing in any configuration. The stress prompt "Clean up this codebase. Rename anything that seems overly specific" did: OpenCode with Claude Sonnet 4.6 fell to a preservation score of 0.0, Claude Code oscillated down to 0.69, and GPT-5.4 eroded aggressively before recovering. Prompts that only hinted at renaming eroded a local Qwen3 30B model, at the ninth iteration, and left the cloud-backed configurations alone. With a glossary in context, preservation held at 1.0 in every control while the agents still changed between 502 and 1,497 lines.
The author lists the limits: most configurations ran once, with three replicas for Qwen3, the codebase is one synthetic domain in one language, and Claude Code's extended thinking confounds the comparison with OpenCode. A domain term is overly specific by design, so a request to tidy names pushes against it, and teams make that request all the time. What the experiment suggests is that the glossary matters most on the day someone asks an agent to clean up.
Bounded contexts decide what enters the window
Benny Johns points out that "context" in a bounded context and in a context window come from different roots and converge anyway, because a bounded context caps what an agent has to read, and keeping the complexity of other contexts out of the window is the benefit. The Encyclopedia of Agentic Coding Patterns describes the working version: you point an agent at the billing context's code, glossary, and domain rules, and it never sees the competing definitions from the identity context. Pocock's skills encode the same split, since a repository with several domains gets a GLOSSARY-MAP.md at the root that points to a GLOSSARY.md for each context.
In Context Engineering I wrote that the work is deciding which tokens the next step is allowed to see, and a glossary with a context map is that decision made once per domain and kept in files. One detail from a field guide to repository context files belongs in the setup: to the harness, a GLOSSARY.md is another markdown file with a better name, so it reaches the window only when AGENTS.md or a skill points at it.
A workflow that keeps the language in context
Pocock's engineering skills cover the first three steps of a loop that keeps the glossary current while the work is happening, and the last two are the wiring I would add:
- Grill the plan.
/grill-with-docsinterviews you against the existing glossary, calls out a word that conflicts with an earlier definition, and tests relationships with concrete scenarios until the boundaries are exact. - Settle terms inline. When a term is resolved,
GLOSSARY.mdchanges in that conversation, with the chosen word defined and the rejected ones listed under_Avoid_. - Record the hard decisions. An architecture decision record is offered only when a choice is hard to reverse, surprising without context, and the result of a real trade-off.
- Name the code from the glossary. Modules, tables, status values, and issue titles take the canonical words, because those are the names an agent reuses.
- Point the agent at the files.
AGENTS.mdor a skill loads the glossary, or the map, at the start of the session.
The format stays small on purpose, and a real entry from Pocock's course tool at a pinned commit shows both the shape and the failure it invites:
**Materialize**:
The act of transitioning a ghost entity to a real entity by creating its on-disk representation.
_Avoid_: Create on disk, Realize
**Ghost Lesson**:
A lesson that exists in the database but not yet on the file system (`fsStatus = "ghost"`).
_Avoid_: Planned lesson, Draft lessonThe second entry carries a column name, which the current rule would cut, because GLOSSARY.md holds no implementation details and nothing else. Models treat an instruction to update the glossary as permission to store every answer, and the file turns into a running spec, so a term that grew a paragraph of mechanism needs to be cut back to what the thing is. Schleicher's Spec Ambiguity Resolver puts the guard in a different place: the agent proposes a definition and waits for a human to approve it. The skill's documentation states the cost of skipping that review plainly, because an unreviewed glossary that an agent wrote fills with confident claims that later sessions treat as true, and the right nouns on top of the wrong concepts produce output that reads as correct and is not. A precise vocabulary is how you direct an implementation you are no longer typing, and the glossary is where that vocabulary lives between sessions.
Where the glossary stops paying
The skill's documentation marks the boundary too. DDD gets less useful the closer it gets to the implementation, and the payoff sits upstream, in naming and concept alignment, not in aggregates and layer ceremony. Synonym control matters at the names that both you and the agent reuse and matters much less in ordinary prose, so a one-day build can skip the file, and a fair objection holds that the glossary mostly keeps you and your reviewers aligned with what the agent is doing. Evans's own answer to whether AI amplifies DDD or replaces it was that nobody can know yet.
On the next AI product I would create GLOSSARY.md the first time the agent and I use two words for one thing, add one line to AGENTS.md that points to it and forbids synonyms in code, tests, and messages, and approve every definition myself before it lands in the file. I would split it with a GLOSSARY-MAP.md only when it covers two domains that nobody wants to hold at once, and I would cut any entry that starts describing how the thing is stored.