A while ago, at the close of a longer run of plots on microservices and DDD, I promised I would come back to Bounded Context and give it more care. I am, as usual, late. But the delay has an upside: the topic arrives now with a new character standing in the middle of the stage, one I could not have written about then. So let me keep the old promise and pay the interest at once.
As usual, let's begin with a loaned idea. Eric Evans gave us the Bounded Context, a border inside which a model means exactly one thing, with a ubiquitous language that holds only within that border. Draw the borders well and each part of the business keeps its own dialect, without the whole enterprise sliding into a tower of Babel.
The hard part was never drawing one border. It was the seams what happens when two contexts must talk to each other. That conversation is what Evans, and later Vaughn Vernon at much greater length, named Context Mapping: the catalogue of relationships two bounded contexts can have. I left that catalogue closed last time. I want to open it now, because a new actor has walked onto the stage who does not respect a single border we drew.
I mean, of course, the AI. More precisely, the large language model, and the agents we are all busy wiring into our systems.
Plot 1 - The Machine That Speaks Every Language
Allow me a small game, the kind I enjoy. In my older note I used the word "order": the order a customer places while buying, and the order a warehouse reads while shipping. Same word, same spelling, different data, different behaviour. Two contexts, two meanings, and an architect's job is to stop them bleeding into one another.
Now go and ask a large language model, "what is an order?"
You will get a confident, fluent, well-structured paragraph that belongs to no context at all. It is the average of every order the model has ever read; purchase orders, court orders, holy orders, restraining orders, your order of operations from school. The model has read all of our contexts and lives inside none of them. This is not a defect you can scold out of it. It is what the thing is. A language model is, by construction, a context-collapsing machine.
Hold that phrase. It will do a lot of work in this note.
Plot 2 - Why Bounded Context Matters More, Not Less
The fashionable reflex runs the other way. "The models are so capable now! do we still need all this modelling ceremony? Just give it the data and let it work out the domain." I hear a version of this in nearly every room, and in my view it is exactly backwards.
A machine that flattens meaning is precisely the thing that most needs a border drawn around it. The discipline of the bounded context is the only mechanism we have for telling the model which meaning of "order" it is permitted to use in this room. Take the discipline away and you do not get understanding. You get fluent nonsense, delivered at a scale and with a confidence no junior analyst could ever manage.
Look closely at what we actually do when we "ground" a model, or bolt retrieval onto it. Squint, and it is an old friend in new clothes: we are handing the model a bounded context to stand inside, and a language to speak while it is there. We did not invent a new idea. We rediscovered Evans, the hard way, because we tried to skip him first.
George Box warned us once that all models are wrong, but some are useful. He meant the statistical kind. Today we carry two models at the same time (the statistical one inside the machine and the domain one inside our heads) and both halves of his sentence apply to both of them. Keeping them honest is the whole job.
Plot 3 - The Map Gets a New Kind of Relationship
Here is the part I owe you from last time. The context map is the set of relationships between contexts, and the good news is that we need no new patterns for the AI. The old ones fit it disturbingly well. Let me recast a few with our new actor in mind. (At the system level, please! I am not arguing about which library wraps which API)
The Anticorruption Layer
The most important relationship in the age of AI, and it is not new at all. You place a translator between the probabilistic stranger and your domain, and nothing the model says enters your model without passing through it. The machine can be as loose, creative and approximate as it likes on its own side of the wall; on your side, "order" still means one thing. If you build a single pattern this year, build this one.
The Conformist
The lazy default, and the dangerous one. Here you let your context bend to whatever the model happens to emit. You reshape your domain around the machine's output because arguing with it is exhausting. It is seductive precisely because the output sounds so authoritative. Resist it. A conformist relationship with a context collapsing machine is how carefully drawn borders quietly dissolve.
Open Host and Published Language
If you want an agent to be a good citizen of your system rather than a guest rummaging through the cupboards, give it a published language to speak (an explicit, documented contract) instead of leaving it to infer one. An agent improvising your domain's grammar is a bug with good manners.
Shared Kernel
Tempting, occasionally right, mostly a trap: sharing a slice of model directly with the machine. Reach for it only where two parties genuinely change together, which an autonomous model rarely does.
Same map. New traveler. The patterns we already had are the ones that tame it.
Plot 4 - The Politics of the Seam
I cannot write about boundaries without returning to the line I keep returning to:
Boundaries are always subject to negotiation.
The seam between two human teams was already political; whose model wins, who maintains the translation, who gets paged when it breaks. Conway's old law never left the room. Now add a participant who sits in no team, attends no stand up and reads no org chart, yet touches every context at once. Who owns the agent's "understanding"? Who owns the anticorruption layer between it and the domain? These are not model questions. They are ownership questions, and politics will answer them whether we plan for it or not.
There is a quieter danger too, and I wrote about it some years ago in another note. Every organization keeps a great deal of knowledge unwritten, in the heads of a few people, in the way things are simply done. A human newcomer learns to ask. The machine does not ask. It fills the silence with confident invention. The unwritten rules of your domain are exactly the rules it will get wrong most gracefully.
The Denouement
So, has the AI made our modelling obsolete? My answer, perhaps predictably, is no. It did something more useful. It stress tested the borders we drew, and it exposed the ones we never really drew at all.
The teams who took bounded contexts seriously (who agreed a ubiquitous language and built honest translation at the seams) will absorb the AI as simply one more actor in the cast, a gifted and slightly unreliable one. The teams who hoped a clever enough model would finally relieve them of understanding their own business will get fluent nonsense, faster than before, and they will call it progress for a while.
Business before architecture, still. Ubiquitous language before model weights. The order of the words has not changed; only the urgency has.
I will leave Event Storming with a model in the room, and the governance of agentic seams, for another plot. Another story for another day, as I am fond of saying.
Let's Summarize
- A language model is a context-collapsing machine: it has read every context and belongs to none.
- That makes bounded context more necessary, not less. Grounding and retrieval are, in essence, lending the model a context to live inside.
- The classic context-mapping patterns transfer to AI actors with almost no translation. Reach for the Anticorruption Layer first; the Conformist is the trap to avoid.
- The hardest part is not technical. It is ownership of the seam, and the tacit knowledge the machine will confidently get wrong.
- Get the borders right, and AI is one more member of the cast. Skip them, and it is a very articulate liability.
..and for reference
As ever, this was written across a few sittings and some links may have aged; email me if I have misremembered a debt or missed one.
Eric Evans - Domain-Driven Design (the blue book), on Bounded Context and Context Mapping
Vaughn Vernon - Implementing Domain-Driven Design, for the context-mapping patterns in practice
Melvin Conway - "How Do Committees Invent?", for the law that never leaves the room
George Box - on models being wrong yet useful
My own earlier plots on microservices, DDD and TOGAF, where this one was promised
Cheers,
Mohammad Malekmakan
Disclaimer:
All opinions and content published in my blog and my social networks are solely my own, not those of my employer(s) and the communities I am contributing in.