The Boundary Between Coupling and Cohesion: Why Low Coupling Alone Doesn’t Make a Good Architecture
Coupling gets all the credit in architecture reviews. Cohesion, its quieter counterpart, is what actually decides whether that low-coupling win was worth celebrating.
Walk into almost any architecture discussion and you’ll hear the same advice: reduce coupling. Fewer dependencies, cleaner boundaries, services that don’t know too much about each other. It’s good advice, and it’s not wrong. But it’s incomplete, and that gap is where a surprising number of expensive redesigns quietly begin.
Coupling tells you how tangled your parts are. Cohesion tells you whether each part actually deserves to exist as its own part in the first place. You can hit an impressively low coupling score and still end up with a system nobody enjoys working in, because the pieces you decoupled were never sensible units of work to begin with.
Two Ideas, Often Confused for One
In plain terms, coupling measures how much one module depends on the details of another. Low coupling means you can change one part of the system without triggering a chain reaction elsewhere. Cohesion measures something different: whether the responsibilities placed inside a single module actually belong together. High cohesion means a module has one clear job, and everything inside it exists to serve that job.
These two ideas are often treated as a package deal, as if pursuing one automatically delivers the other. It doesn’t. You can split a system into a dozen tidy, loosely coupled services where each one still contains a grab-bag of unrelated logic. The coupling metric looks great. The day-to-day experience of working in that codebase does not.
Why Low Coupling Can Still Disappoint
Picture a team that splits a monolith into several services purely to reduce inter-module calls. Each new service ends up loosely connected to the others, which is exactly what was asked for. But inside one of those services sits a mix of billing logic, notification logic, and reporting logic, thrown together simply because they happened to live in the same original file. The coupling problem is solved. The cohesion problem has just been relocated.
Every future change to billing now risks breaking notifications, because the two were never truly separated, only moved together into a smaller box. Low coupling reduced the blast radius between services. It did nothing to reduce the blast radius inside one.
The Four Combinations That Matter
It helps to think of coupling and cohesion as two separate dials, not one. Plotting them against each other produces four broad outcomes, and only one of them is genuinely the goal.
The bottom-right quadrant, low coupling paired with high cohesion, is the one every team is actually chasing when they talk about “clean architecture.” The other three all look different on paper, but each one carries its own hidden cost, and coupling metrics alone will never reveal which quadrant you’re actually standing in.
| Combination | What It Looks Like | Hidden Risk |
|---|---|---|
| High Coupling, Low Cohesion | Tangled dependencies, unclear module purpose | Highest maintenance cost; changes ripple everywhere |
| Low Coupling, Low Cohesion | Independent services, but each one is a grab-bag | Looks healthy on dependency graphs, feels messy to work in |
| High Coupling, High Cohesion | Each module has a clear purpose, but modules over-share | Focused teams, but changes still cascade across boundaries |
| Low Coupling, High Cohesion | Clear-purpose modules that rarely need to know about each other | The actual target; lowest long-term change cost |
Why This Distinction Matters Beyond the Codebase
This isn’t just a naming exercise for engineers. It has a direct line to cost and speed, which is exactly why it’s worth attention outside engineering conversations too. A study analyzing several well-known open-source projects, including Apache Camel, Xalan, Tomcat, Ant, and Xerces, found that most design metrics rose alongside defect counts, but cohesion moved in the opposite direction: as classes became more cohesive, reported bugs tended to drop. Coupling metrics alone did not tell that story nearly as cleanly.
Translated into business terms, that means the modules doing one job well are the ones costing you less in support tickets and rework, independent of how neatly they’re wired to everything else. A team can hit every coupling target on the dashboard and still be surprised by how often a “simple” change breaks something unrelated, because the true source of that fragility was never coupling. It was a module trying to do too many unrelated things at once.
How Cost Actually Tracks Across the Four Quadrants
The chart below illustrates how the cost of making a typical change tends to shift as you move between these four combinations. It’s a conceptual illustration rather than a measured benchmark, but it reflects a pattern architects encounter repeatedly: cohesion, not coupling, is usually the bigger swing factor once a system reaches meaningful size.
Notice that the jump from low cohesion to high cohesion tends to matter more than the jump from high coupling to low coupling. That doesn’t make coupling unimportant. It means cohesion is frequently the more expensive blind spot, precisely because it gets far less attention in day-to-day design reviews.
Quick Checklist: Are You Actually Improving the Architecture?
- Before splitting a module, ask what its single responsibility actually is, not just how to reduce its dependencies.
- Track how often a “single” feature change touches multiple unrelated concerns inside one module.
- Treat a shrinking dependency graph as encouraging, not conclusive, evidence of good design.
- Revisit cohesion whenever a service keeps absorbing unrelated responsibilities over time.
- Remember that a cohesive module can tolerate some coupling far better than a scattered one can tolerate none.
What We Learned
Coupling and cohesion are often taught as a single principle, but they answer two different questions. Coupling asks how dependent your modules are on each other. Cohesion asks whether what you put inside each module belongs there at all. A system can achieve low coupling and still disappoint, because the real cost driver was never how the pieces connected, but whether each piece made sense as a unit of work in the first place. The teams that get the most out of their architecture are the ones who treat cohesion as a first-class design goal, not an afterthought to a clean dependency graph.
