Confession: I’m in a book club, and the book we’re reading right now is a 500-page software design textbook from 2003. So yes, it’s that kind of book club.
The book is Domain-Driven Design by Eric Evans. It has nothing to do with AI. It came out about 20 years before ChatGPT, back when the hard problem in software was getting a program to match how a business actually worked. And yet I keep hitting chapters and thinking “this is exactly what businesses get wrong when they start using AI.”
So here’s the pitch: four ideas from a book about software, translated for anyone trying to figure out where AI fits in their business. No code required.
The short version: AI doesn’t fix a process nobody has defined. It runs that process faster, mistakes included. The book’s lessons are about defining things first.
The book’s big idea, in one sentence
Evans opens with a line that has stuck with me:
“The heart of software is its ability to solve domain-related problems for its user.”
“Domain” is just the book’s word for the business itself: the work, the language, the rules, the way things actually get done. His argument is that the hard part of building software was never the technology. It was understanding the business well enough to model it properly, because a program can only be as clear as the thinking behind it.
Swap “software” for “AI” and the sentence still holds. Maybe more so. AI tools are fast, cheap, and eager to please. If your process is fuzzy, they won’t push back. They’ll confidently produce fuzzy results at scale.
Which brings me to the lessons.
Lesson 1: Agree on what your words mean
The concept Evans is probably best known for is the Ubiquitous Language: one shared vocabulary, used by everyone from the owner to the person building the software, with every term meaning exactly one thing.
Let’s make up a business. Say it’s a small plumbing and heating company with a dozen people. Ask around the office what “a job” is and you’ll get three answers:
- To the person answering the phone, a job is a quote that’s been sent out.
- To the techs, a job is a work order with an address and a time window.
- To the bookkeeper, a job is something that can be invoiced.
Nobody is wrong. Everyone has been getting by on context for years. Then somebody drops in an AI assistant to “summarize open jobs” and it quietly picks one definition. Or worse, it blends all three, and now the Monday report counts unsent quotes as scheduled work.
AI tools run on words. Your prompts are words, your documents are words, your database columns are words. If the words are ambiguous to the people who work there, they’re at least as ambiguous to the model, and the model won’t tell you when it’s guessing.
What to actually do: write the glossary. One page. Every term your business uses that matters, with a definition everyone signs off on. It’ll take a meeting, and the meeting will involve arguing. That arguing is the valuable part. Evans’ whole point is that hashing out the language is the work of understanding your business, and you can’t skip it by handing the confusion to a machine.
Lesson 2: Draw the boundaries
Here’s the twist. Sometimes “job” should mean different things in different parts of the business, and that’s fine. Evans calls these Bounded Contexts: areas where a term has a specific meaning, with a clear line around them.
In our plumbing company, “job” in the scheduling world (address, tech, time window) and “job” in the bookkeeping world (line items, amounts owing) are legitimately different things. The problem isn’t that they differ. The problem is when nobody has said out loud where one world ends and the other begins.
This matters for AI because the most common mistake I see is giving one tool access to everything and hoping it figures out the structure. It won’t. Data from three contexts, dumped into one place, just looks like noise with a lot of duplicate columns.
What to actually do: scope each AI use to one context. An assistant that helps dispatch techs gets scheduling data and speaks the scheduling vocabulary. A tool that drafts invoices lives on the bookkeeping side. When something needs to cross the line, you decide how “job” translates from one side to the other, in writing, before the tool does it for you.
Lesson 3: Spend on the core, buy the rest
Evans spends a lot of the back half of the book on what he calls distillation: figuring out which part of the business is the Core Domain, the part that makes you different and makes you money, versus the Generic Subdomains, the parts every business has and nobody wins on.
For our plumbing company, the core is probably diagnosing problems fast and getting the right tech with the right parts to the right house. That’s the reputation. Invoicing, payroll, email, scheduling software? Necessary, but nobody picks a plumber because their invoices are beautiful.
The AI version of this is a budgeting rule:
| Part of the business | What it is | How to approach AI here |
|---|---|---|
| Core domain | The thing you’re actually better at than competitors | Worth real effort: custom tooling, your own data, your own rules, careful design |
| Supporting | Specific to you, but not a differentiator | Configure off-the-shelf tools around your glossary; don’t build |
| Generic | Every business has this (bookkeeping, email, HR) | Buy the boring, well-supported option and move on |
I see a lot of small businesses do this backwards. They put serious energy into an AI email assistant (generic) while the thing that actually makes them money runs on a spreadsheet and one person’s memory (core). Evans would say the effort is going to the wrong place. I’d agree.
What to actually do: before you evaluate any AI tool, write down what your core domain is in one or two sentences. If a tool doesn’t touch it, buy the cheapest reliable option and stop thinking about it. Save the bespoke work, and the bespoke budget, for the core.
Lesson 4: Keep a layer between you and the model
Last one, and it’s the one I’d push hardest on if you’re already using AI today.
When your system has to talk to an outside system you don’t control, Evans recommends an Anti-Corruption Layer: a translation step that converts between your model of the world and theirs, so the outside system’s assumptions don’t leak in and quietly reshape yours.
That’s exactly the relationship you have with an AI vendor. The model has its own idea of what an “order” or a “customer” or a “job” is, learned from the whole internet, not from you. Its output format is whatever the vendor decided. Its behaviour changes when they ship a new version. Its price changes when they feel like it.
If your business process is written in the vendor’s terms, in the vendor’s tool, then you don’t really own your process anymore. Swapping tools becomes a rewrite. Everyone starts using the tool’s words instead of your words. The corruption goes both ways.
What to actually do: keep your process, your glossary, and your rules written in your own language, somewhere the vendor doesn’t control. Then treat any AI tool as something you translate into and out of. Your definition of “job” goes in, the model does its thing, and the result gets checked against your rules before anyone acts on it. It sounds like extra work. It’s mostly a habit, and it’s the difference between “using AI” and actually leveraging it to extend what your business can do.
Skip the layer and you can get slop. Maybe not on day one, but eventually. A quote goes out with a line item nobody offered. A summary confidently counts the wrong thing. A customer email reads like a machine wrote it, because one did. Best case, it looks lazy. Worst case, it costs you money or a customer, and you find out after the fact.
Fit the tool to the business, not the other way around
The whole book is really about one idea: software should bend to fit the business, not the business to fit the software. Most of the pain Evans describes came from companies that let it go the other way.
We’re at the same fork with AI, except the tools are more persuasive and the decisions get made faster. The businesses that get real value from this stuff aren’t the ones with the fanciest models. They’re the ones who could explain, in plain language, how their business works before they asked a machine to help with it.
If you want a place to start this week:
- Write the one-page glossary. Argue about it.
- Draw the boundaries. Which parts of the business use which words?
- Name your core domain in two sentences.
- Look at every AI tool you already use and ask whether you could swap it out next month without a rewrite.
None of that requires buying anything. Most of it requires a whiteboard and an afternoon.
And if you’d rather work through it with someone who has read the 500 pages so you don’t have to, that’s roughly what I do at Fread.