---
title: "Domain-Driven Design: draw the bounded context before the glossary"
description: "Evans put bounded contexts in chapter 14, but when agents write most of the code, I think the boundary needs to come before the glossary."
url: "https://michael.zazon.us/notes/domain-driven-design-draw-the-bounded-context-before-the-glossary"
published: "2025-11-26T12:00:00-05:00"
kind: "book-notes"
subject: "architecture"
tags: ["ddd","agents","ai-coding"]
---
Most of the DDD that I see reaching codebases is the tactical half: aggregates, repositories, a folder for each "domain", and the team calls the result DDD. I think the tactical half will be less useful when coding agents write a lot of code. An agent can generate a repository in seconds. But it can't on its own decide where one model stops and the next one starts, which is the strategic half of [Eric Evans' book](https://www.domainlanguage.com/ddd/).

A common move right now is to drop a glossary into the agent's instructions and feel responsible. But if "account" means a ledger with a balance in billing and a user with a password and session for login, a single glossary needs to pick one meaning and the agent will happily spread that meaning across every part of the system it touches, even where it's wrong.

I'd argue to first set up a bounded context. A glossary without a boundary is just a word list the agent will apply everywhere. But once you draw that boundary, each context gets its own short term set. "Account" can mean a ledger in one context and a login in another, and the agent won't get confused.

Evans seems to agree on the ordering too. Ubiquitous language is early in the book, but bounded contexts aren't until chapter 14. In a [2009 talk](https://gojko.net/2009/03/12/qcon-london-2009-eric-evans-what-ive-learned-about-ddd-since-the-book), he called that placement "one of the few regrets he has about the way he wrote the book" and said "the reality is that there is always more than one model". So if the person who named the pattern wishes he'd put boundaries first, I'm comfortable putting them first in a prompt. (As an aside, he later compared a trained language model to a bounded context in a [2024 keynote](https://www.infoq.com/news/2024/03/Evans-ddd-experiment-llm/))

The reason the tactical patterns matter the least to me right now is that the agent can generate aggregates and repositories all day. The strategic part (where to put the lines, what the words inside mean) is the work that's left to people. One question I keep coming back to is how people keep the language up to date inside each context when agents are writing most of the code inside it.