The system made sense when we built it. Three years later it is the thing we most dread working on.
The database tables stopped reflecting how the business thinks about customers. Service boundaries cut across capabilities in ways that force every feature to touch five teams. A term means one thing in the product group and something completely different in finance. Nobody can trace where it started.
This is a modeling failure. And it happens in every organization I have ever visited, at every scale.
Eric Evans put a name to this pattern in 2003. Domain Driven Design. The core idea is simple and frankly a bit obvious once you hear it: a software system’s design model should reflect the domain it serves. When the model and the domain drift apart, the cost of change rises. Not because the technology is wrong. Because the structure underlying the technology has lost alignment with the business reality it was built to represent.
That idea has accumulated two decades of community practice, and the tools it produced are directly applicable to every flavor of architect work. Business, information, infrastructure, software, solution. All of it.
But first, a word problem
We need to talk about the word “domain” because it might be the 2nd most overloaded word in our profession (the first being architecture)… actually it probably belongs on a list of overloaded terms… ok now I have to start that article 🙂
I hear architects use it to mean a technology capability, scope, a business function, an org chart unit, a value stream, and sometimes just a vague label for whatever they are currently responsible for. Each of these usages reflects something real. And each of them creates confusion when you try to have a precise conversation about boundaries and ownership.
The BTABoK’s position is that “domain” should mean one specific thing: the sphere of concepts, rules, and language that surrounds a business capability cluster. The capability names what the organization does. The domain organizes the things and rules involved in doing it. Verbs for capabilities, nouns for domains.
That distinction matters more than it looks. Because once you are clear on it, the rest of DDD starts to make practical sense.
The bounded context is the unit of architecture
The most important concept in DDD for architects is the bounded context. It is an explicit boundary inside which a single domain model applies consistently. Inside the boundary every term has a precise agreed definition. Outside the boundary the same word may mean something completely different.
Evans illustrates this with a “customer.” A large organization has a customer in sales, a different customer in billing, and a third in customer service. These are not the same model. Trying to build one unified Customer object to satisfy all three produces something with dozens of conflicting fields and coupling that means a billing change breaks something in sales.
The bounded context says: treat these as separate models, with separate teams responsible for each. The shared vocabulary is a coincidence, not a modeling obligation.
That realization alone tends to unlock a lot of energy in stuck teams. Because the real problem was never the technology. It was the insistence on a single model for things that are fundamentally different.
Not every domain deserves equal investment
DDD classifies subdomains as core, supporting, or generic. Core is where the business has real competitive differentiation. Supporting is necessary but not differentiating. Generic is a standard problem with a standard solution.
This connects directly to the BTABoK capability model. Where a capability is core, you invest in a rich domain model, real domain expertise in the team, careful architecture. Where a capability is generic, you buy a solution and put a protective integration layer around it. You do not build a custom expense reporting engine from scratch. You buy one and isolate it.
Architects who are not asking this question about every significant investment area are leaving a lot of value on the table. And frankly letting their organizations waste money on the wrong things.
The organization is the context signal
Something the DDD community has gotten clearer about over the years is that context boundaries often come from the organization before they come from any technical analysis.
A sales context exists because the sales organization has its own vocabulary, its own data ownership, and its own experts who define what a prospect and a pipeline stage mean. An HR context exists because HR governs a distinct domain with its own regulations and its own language. These are real architectural inputs. Not accidents of Conway’s Law to be worked around.
In the BTABoK, the BIISS model recognizes that each specialization, business, information, infrastructure, software, solution, understand impact on capability, domain and scope. This is a scientific process more than an art. A platform that serves all five needs to respect the vocabulary and boundary differences between them. That is a practice design observation.
What I would do this week
Take one system you currently work on. Pick the most overloaded concept in it. Something like customer, account, product, or order. List every place in the system where that concept appears. Ask whether it means the same thing in each context.
Where it does not, you have a bounded context boundary hiding in plain sight. That is your starting point.
DDD is not a coding framework. It is a design philosophy built on the observation that software should reflect the domain it serves, and that maintaining that reflection takes deliberate shared work by technical and domain experts together. It remains one of the sharpest tools we have for drawing boundaries that hold.