Here is a question that looks innocent. In your company, what is a customer?
Ask the billing team and they will say a customer is someone with a payment method, a billing address, invoices, and a credit status. Ask the support team and they will say a customer is someone with open tickets, a satisfaction history, a preferred language, and a phone number that actually works. Same word, two different things. Both teams are right.
Now here is the expensive part. Most companies try to fix this by building one Customer class, one customer table, one “single source of truth” that serves everybody. And that decision, made with the best intentions, quietly creates years of meetings, merge conflicts, and delays. I want to explain why, and what Eric Evans figured out about it almost twenty years ago.
The god model problem
When billing and support share one Customer model, every field belongs to everyone and to no one. Billing needs to add a tax exemption flag. Support needs to change how contact preferences work. Both changes touch the same class, the same table, the same code. So now billing’s deploy can break support’s screens. Support’s migration locks billing’s table. Every change needs a meeting with the other team, then a careful review from both sides, then a coordinated release.
Multiply this by five teams and one shared model, and you get the company where shipping a small feature takes a month, and nobody can say why exactly. Any resemblance to a company you have worked for is pure coincidence . The why is hidden in coordination cost. People stepping on each other does not appear in any report, it just makes everything a little slower, every day, forever.
I lived this in my agency years. Two teams, one shared “core” library, and a calendar full of alignment meetings. The meetings felt professional. They were actually the symptom.
What Evans saw
Eric Evans published Domain Driven Design in 2003. The book is famous for many ideas, but I think the most valuable one, the one I would keep if I had to throw away the rest, is the bounded context.
The idea in plain words. Do not fight for one universal model. Accept that “customer” honestly means different things in different parts of the business. Draw an explicit boundary around each part. Inside the boundary, the word has exactly one meaning, the model is consistent, and the language is precise. Across boundaries, you translate, explicitly, at the border.
So billing gets its own Customer, with payment methods and credit status. Support gets its own Customer, with tickets and preferences. They share an identifier and exchange information through defined contracts, events or APIs. Neither team can break the other by accident, because there is no shared code to break.
It feels like duplication, and people resist it for that reason. It is not duplication. The two models were never the same thing. They were two different concepts wearing the same name, handcuffed together. The bounded context just removes the handcuffs.
Contexts map to teams, and that is the point
Vaughn Vernon, whose book Implementing Domain Driven Design made these ideas practical for a lot of us, and who writes at vaughnvernon.com, makes a point I repeat in every architecture discussion. Bounded contexts work best when they map to team ownership. One context, one team, one model, one deployable thing if possible.
When the map is clean, look at what happens to the daily friction.
Merge conflicts drop, because two teams are no longer editing the same files for different reasons. Meetings drop, because billing does not need support’s approval to change billing’s own model. Inside their boundary, a team can refactor, rename, and redesign without asking permission from anyone, and that autonomy is exactly what makes delivery fast. The only conversations left between teams are about the contracts at the border, and those are rare and worth the time.
There is a money line hiding here, so let me say it directly. Coordination is the biggest hidden cost in software organizations. Engineers are expensive, and an engineer waiting for another team is the same salary producing nothing. Bounded contexts are an architecture decision, but what they really buy is fewer people blocked by other people. That is why this is a business topic, not only a modeling topic.
A small honest example
At Benevity I work in a Giving domain with donors, causes, and companies, and the same lesson appears here too. The word “donation” does not mean the same thing to the part of the system that processes money and the part that reports impact. One cares about cents, currencies, and settlement. The other cares about totals, causes, and stories. Forcing one model to serve both would make both teams slower and both models worse. Keeping them separate, with a clear contract between them, lets each side move at its own speed.
The hardest part is not technical. It is accepting that the company dictionary has more than one page. People feel that one shared definition is “cleaner”. As an immigrant I find this funny, because I live between two languages every day, and translation at a clear border works fine. It is much better than pretending two languages are one.
The note I keep for myself
Evans gave us the concept in 2003. Nineteen years later, I have never seen a fast organization that ignored it, and I have never seen a slow one that could not be explained by it. That is not science, that is just my scars talking.
Good fences make good neighbors. Bounded contexts are the fences.
Pax et bonum.