Cohesion and Coupling

This concept is the foundation for making every software architecture decision you will ever face. Understanding cohesion and coupling is the key to judging whether a system's boundaries are drawn well, whether a change will be cheap or expensive, and whether a codebase can be tested at all. It unlocks the rest of your library: Layered Architecture, Hexagonal Architecture, Ports and Adapters, Dependency Inversion, and Microservice Cost Tradeoffs — all of them are just different strategies for achieving high cohesion and loose coupling. Master these two ideas and you'll be able to look at any system — a monolith, a microservices fleet, an AI pipeline — and say where the pain will come from.

Think of a software system as a collection of boxes (called modules). Each box contains some code — functions, data, logic. Cohesion asks: *how closely related are the things inside one box?* Coupling asks: *how much does one box depend on the contents of another box?*

A module with high cohesion has a single, clear purpose. Everything inside it belongs there. You can name it in a sentence: "This module handles user authentication." Open it, and you find only authentication-related code. A module with low cohesion is a junk drawer. It contains a bit of this, a bit of that. You can't name it without an 'and': "This module handles user authentication, and also file I/O, and occasionally formatting dates." Nothing in it is closely related to the rest.

Coupling, on the other hand, is about the *connections between* boxes. Two modules are loosely coupled if they know very little about each other's internals. They communicate through a small, clear interface — like a plug and socket. One can be changed or replaced without disturbing the other. Two modules are tightly coupled if one reaches inside the other, reads its private variables, or relies on precise steps happening in a particular order. Change anything in one, and the other breaks.

The two ideas pull in the same direction. High cohesion inside modules naturally leads to loose coupling between them, because if each module has a single clear job, it exposes only what's needed to do that job. Low cohesion forces tight coupling, because a junk-drawer module has its tentacles in everything — other modules have to know about all the unrelated things it does just to use any part of it.

Real software starts out neat but rots toward low cohesion and tight coupling. Every time a developer adds a feature, they are tempted to bolt it onto an existing module because it's convenient. The code in each box becomes more unrelated, and the boxes become more tangled. This concept gives you the vocabulary to notice that rot and the target to push back toward.

Think of a restaurant kitchen. The kitchen is divided into stations: the grill, the salad prep, the pastry section, the dishwashing area. Each station has a clear purpose — this is cohesion. The grill station only grills; the pastry station only bakes. Any chef walking in knows where to find what they need and what each station is responsible for.

The stations also have a way of working together — this is coupling. The grill needs raw meat from the walk-in fridge; the pastry station needs butter from the same fridge. They communicate through a small, standard interface: a ticket with the order, a shelf where finished plates are placed. The grill chef doesn't need to know how the pastry chef folds croissant dough. The pastry chef doesn't need to know the grill's temperature settings. They just exchange what's necessary through the pass.

Now imagine the opposite — a kitchen where the grill chef stores their spices in the pastry section's cabinet, and the salad prep's cutting board is also used for plating desserts. The stations are now coupled: pastry can't work if the grill chef is in the way; salad prep can't be cleaned without disturbing the pastry station. And within each station, cohesion has broken down — the pastry section now contains spices that belong to the grill. The kitchen becomes a mess: nobody can work independently, every change to one station affects the others, and the whole operation grinds to a halt.

The analogy stops working when you consider that in software, the modules aren't people who can talk it out. They're code. A module can't adapt or communicate — it either knows the other module's internals or it doesn't. The 'interface' is not a plate on a shelf; it's a carefully defined set of function signatures and data structures. And in software, the cost of coupling grows non-linearly: two modules that are tightly coupled cause four times as many problems as one, not twice as many.

Cohesion is the degree to which the elements inside a single module belong together; coupling is the degree to which one module depends on the internals of another. The goal is high cohesion and loose coupling.

This sits alongside Separation of Concerns and Single Responsibility as the foundational criteria for judging any architectural decision. Separation of Concerns says distinct responsibilities should live in distinct places; cohesion is how you tell whether a place actually holds one responsibility or several. Single Responsibility says a module should have one reason to change; cohesion is how you tell whether the contents justify that single reason. This concept will be the lens through which you later evaluate Layered Architecture (are the layers cohesive? is the dependency direction coupling only to the layer beneath?), Hexagonal Architecture (the core has high cohesion and zero coupling to the outside world), Ports and Adapters (ports are pure interfaces that decouple the core), and Dependency Inversion (depending on an abstraction instead of a concrete implementation is the ultimate way to loosen coupling).