Cohesion

What Cohesion Means in Software Design

Cohesion describes how closely the responsibilities inside a component fit together. When cohesion is high, the component has a single, understandable purpose and tends to be easier to reason about, test, and change without unexpected side effects.

Low cohesion usually means a component is carrying unrelated work, which makes behaviour harder to predict and increases the chance that a change for one purpose breaks another. That is why cohesion is often discussed alongside modularity, separation of concerns, and maintainability.

Why Cohesion Matters for Security and Governance

Cohesion is not a control by itself, but it shapes how well security decisions can be applied inside a system. Components with clear purpose are easier to review for access boundaries, data handling, logging, and approval logic because the security-relevant behaviour is concentrated rather than scattered across unrelated code paths.

From a governance perspective, cohesion also affects ownership. A component that does one thing has a clearer owner, clearer test scope, and a cleaner change history. When responsibilities are mixed, accountability becomes blurred and reviewers may miss where a risky behaviour actually lives.

Cohesion Versus Coupling

Cohesion is about what belongs together inside one component. Coupling is about how strongly one component depends on another. The two are related but not identical: a design can be highly cohesive yet still too tightly coupled to the rest of the system, or loosely coupled but internally messy.

Good design usually aims for high cohesion and controlled coupling. That combination makes components simpler to evolve, reduces hidden dependencies, and helps teams isolate security-sensitive logic such as authentication checks, data validation, and privilege boundaries.

How to Recognise Strong or Weak Cohesion

A practical sign of strong cohesion is that a component can be described in a single sentence without using “and” to join unrelated responsibilities. A weakly cohesive component often contains mixed workflows, repeated branching for different business cases, or utility methods that do not clearly support the same purpose.

In architecture reviews, low cohesion often shows up as files, services, or modules that are easy to change for one feature but unexpectedly fragile for another. That fragility is usually a design smell, not just a maintainability nuisance, because it often hides unclear boundaries and inconsistent trust assumptions.

Risk and Threat Considerations

Low cohesion can create security risk because unrelated responsibilities tend to accumulate in the same place, making permission checks, data-handling rules, and error paths harder to inspect. It also raises the chance that a change intended for one function alters another function with different trust or sensitivity requirements.

Failure mechanism: responsibilities drift into the same component, so reviewers lose the ability to see where security-sensitive logic begins and ends, and weak boundary decisions survive longer.

Impact: the result can be overlooked access control, inconsistent handling of sensitive data, and harder incident review because the design no longer mirrors the actual security model.

Practitioner Guidance

Why practitioners should care: cohesion is one of the quickest structural signals that a component is becoming hard to govern. If a service, class, or module cannot be described cleanly, it is often carrying too many lifecycle, policy, or trust decisions in one place.

Practitioner takeaway: Treat cohesion as a design-quality check that should be visible in code review, architecture review, and ownership boundaries, not just as an abstract software engineering concept.

Related resources from NHI Mgmt Group

• What is the difference between high cohesion and loose coupling in microservices design?
• Should teams prioritise workflow cohesion or more automation first?
• Semantic Cohesion
• Workflow Cohesion