The acronym I waved off
I’m comfortable with a few of the development acronyms. TDD, test-driven development, I use. BDD, behaviour-driven development, I understand. But DDD, domain-driven design, was always the one I let slide past me.
I’d seen the term before. I knew it existed. I just never paid attention, because from a distance it looked like it was only about agreeing on vocabulary with your dev team or your product team. Defining glossary terms. Naming things consistently.
And honestly, like a lot of engineers, I carry a small bias against anything that smells like marketing, sales, or product packaging. So I filed DDD under “buzzword.” Something fancy you say to impress an investor, a sponsor, or a client. A word that exists to attract attention, not to do work.
I was completely wrong.
What DDD is actually about
The core idea behind domain-driven design is that you design around the vocabulary of a specific domain. You build a glossary, a set of terms that mean something exact inside that context. Not the everyday meaning. The domain meaning.
Take the word “funnel.”
In normal day-to-day language, a funnel is a shape, or a tool, the thing you use to pour liquid into a narrow opening. But in a marketing or social media domain, “funnel” means something completely different. It’s the path that pulls traffic in and leads a person toward your target. The funnel isn’t an object. It’s the flow that captures attention and channels it where you want it to go.
Same word. Two domains. Two meanings that don’t overlap at all.
That’s the whole point of DDD. Inside your domain, you decide what the word means, you write it down, and everyone reads it the same way. Once you see it framed like that, it’s pretty easy to understand.
Why I never bothered
Here’s why it never felt necessary to me as a developer.
I was already living inside the domain. I had the context in my head. My teammates had the same context in theirs. So when someone said “funnel,” nobody got confused. We all knew. Writing it all down into a formal glossary felt like extra work for no real payoff.
So I skipped it. For most of my early working life, DDD looked like ceremony I could afford to ignore, and nothing bad happened when I did.
Then the other side stopped being human
What changed was moving more of my work over to agents.
I still understood every domain term perfectly. The problem was that my agent didn’t. The shared context I’d always relied on, the thing that made the glossary feel pointless, just wasn’t there anymore. The agent walks in with no idea what “funnel” means in my world.
So I found myself explaining the same terms over and over, trying to get the agent aligned with me. Every conversation started with re-teaching the vocabulary.
And the failure mode is exactly what you’d expect. Say “funnel” to an agent with no domain context, and it might picture the tool, the literal object. I don’t want that. I want it to know that, in this domain, a funnel is the pipeline that pulls traffic toward a specific target. I want it thinking about the flow, not the kitchen utensil.
That gap is the same one I wrote about in alignment comes before implementation. We agree on a word, we both walk away happy, and we meant two different things underneath it. The agent version of that problem is sharper, because the agent won’t pause and feel awkward about a term it doesn’t actually know. It just guesses and keeps going.
The fix is embarrassingly simple
The solution is the thing I’d been dodging for years. Build a glossary document. Point the agent at it. Have it read the glossary first, before anything else.
That’s it.
Once the glossary exists, the agent doesn’t misunderstand “funnel.” It checks the document, sees exactly what the term means in this context, and uses that meaning. I stop re-explaining. The agent stops guessing.
And the payoff shows up fast. I stop re-teaching vocabulary at the start of every session. The conversation runs at a higher level, because we’re not stuck negotiating what basic words mean. And the agent stays consistent: every time it hits a domain term, it resolves to the same definition, so whatever a word meant last week, it still means this week.
That last part, the consistency, is the one I underrated most. The glossary becomes a single source of truth for language, and it makes every conversation more meaningful because we’re genuinely aligned from the first message. It connects to the same idea as the spec being the new source code: the document you maintain up front decides the quality of everything the agent produces downstream.
The old patterns didn’t get less important
This whole thing made me rethink a lot of the “old” patterns. DDD, and frankly a pile of established best practices, aren’t relics. Some of them are more important now, not less.
We ignored them, or were too lazy to apply them, because we could get away with it. The shared human context covered for us. Now that an agent sits on the other side of the conversation, the gaps those practices were designed to close are suddenly visible again. So this is the moment to actually adopt them properly instead of nodding and moving on.
It turns out a practice I dismissed as buzzword decoration was solving a real problem the entire time. I just couldn’t feel the problem until my collaborator stopped sharing my brain.
Where I’m landing
DDD is an old idea. I’d heard the term forever and never gave it a real chance. But it’s surprisingly useful, and it’s even more useful in an agent-based workflow than it was before.
The reason comes down to how I think about agents now. For me, an AI agent isn’t really a tool. It’s closer to a coworker, or a member of my own staff. And the moment you treat something as a collaborator, communication becomes the thing that matters most.
So any practice that improves communication, especially one as cheap as writing down what your words mean, is worth the attention. I spent years skipping the glossary because everyone around me already knew. Now I write it down, hand it to the agent first, and let the shared vocabulary do the work.
I dismissed Domain-Driven Design as a marketing buzzword for years. Then I started working with agents that didn’t share my domain context, and a simple glossary turned out to be one of the highest-leverage things I could write.