The decision nobody documents
Most architecture diagrams show services. What they don't show: where one team's responsibility ends and another's begins. That boundary is where most long-term architectural debt originates.
Domain-Driven Design calls this a Bounded Context. The name sounds technical. The decision behind it is not.
What a Bounded Context actually is
A Bounded Context defines where a specific domain model is valid. Inside it, terms mean exactly one thing. "Order" in an e-commerce context means something different to the fulfillment team than it does to finance. Build a single shared model for both, and you've already made a mistake that will cost you later.
The boundary has nothing to do with which database a service uses or which team owns a repository. It defines where a concept retains its meaning. Where the language holds.
Where organizations get this wrong
The most common mistake: drawing Context boundaries along technical lines instead of domain lines. A team owns a microservice, so the service becomes the Context. A database is shared, so two domains collapse into one Context to avoid duplication. An existing org chart defines the boundaries before anyone asks what the domains actually are.
Each of these decisions feels pragmatic in the moment. Six months later, logistics, finance, and customer support are all calling the same "Order Service" with slightly different expectations of what an order is. That's not a technical problem anymore. That's the consequence of a boundary that was never clearly drawn.
The organizational dimension
Bounded Contexts reflect organizational reality as much as domain reality. Conway's Law doesn't care about your architecture diagrams. If two teams share a Context, they will couple. If one team owns a Context that another depends on without a clear interface contract, the dependency will drift.
That's why the decision about where to draw a Context boundary belongs in a conversation between business and architecture. Not to a single architect working alone.
The question isn't "what does our system look like?" It's "where does one team's mental model of the business end, and another's begin?"
Technical debt starts here
Incorrectly drawn Bounded Contexts produce debt that isn't immediately visible. You see it six months later, when a change in one part of the system forces unplanned work in three others. When "refactoring" starts appearing in every planning session. When senior engineers start describing the codebase in terms of "areas we don't touch."
That's not a code quality problem. It's the architectural consequence of boundaries that were never clearly defined, or that the wrong people drew for the wrong reasons.
What a good boundary decision looks like
Three properties mark a well-drawn Bounded Context. The team that owns it can describe what it does without using another team's vocabulary. Changes inside it don't require coordinating with teams outside it, at least not for routine work. The interface to the outside world is explicit, not implicit.
None of this requires special tooling or a specific tech stack. It requires a concrete conversation about what a domain actually means, who owns it, and where its edges are.
That conversation is uncomfortable. Business stakeholders rarely think in terms of domain ownership. Engineers prefer to defer the decision and figure it out later. But deferring is itself a decision, and one that tends to get more expensive over time.
The question for your next architecture review
For each major system, can you answer: do the teams agree on what the domain model inside it means? If the answer involves exceptions, historical reasons, or "it depends on who you ask" - that's your starting point.
