Coupling measures how strongly one component depends on details of another. Cohesion describes how closely the responsibilities inside one component belong together.

A useful module usually aims for high cohesion and low unnecessary coupling: related rules live together, while unrelated parts communicate through small interfaces.

Coupling is not inherently bad. Software must have dependencies to cooperate. The engineering question is whether a dependency points toward knowledge that is stable and genuinely needed.

A dependency on an interface such as StoreOrder(order) is easier to preserve than a dependency on another module's table layout, private fields and call sequence.

Dependency direction also matters. When high-level policy depends directly on volatile infrastructure details, changing the infrastructure can spread through the application. Introducing a boundary can let both sides depend on a more stable contract instead.

Architecture is therefore partly the deliberate placement of dependencies: keep each responsibility coherent and prevent implementation details from becoming accidental system-wide contracts.