Cohesion, Coupling, and Boundary Tension

Cohesion asks whether the things inside a service belong together for reasons the business and the owning team can explain. Coupling asks how much that service depends on other boundaries to do normal work. Those two ideas are the most practical way to judge whether a service is well shaped. When cohesion is weak or coupling is high, the boundary starts to show stress. In this guide, that stress is called boundary tension.

Boundary tension is not one metric. It is the observable pressure that appears when a service is too internally confused or too externally coordinated. That pressure shows up in change patterns, incident patterns, contract growth, and workflow friction.

    flowchart LR
	    A["Internal change pressure"] --> C["Boundary tension"]
	    B["External coordination pressure"] --> C
	    C --> D["Consider split"]
	    C --> E["Consider merge"]
	    C --> F["Consider contract redesign"]

What to notice:

• tension can come from inside the boundary or from its edges
• split and merge are both possible responses
• contract shape matters as much as raw service count

What Strong Cohesion Looks Like

Strong cohesion usually means:

• the service owns related business rules
• most internal changes happen for similar reasons
• the domain language inside the service is consistent
• the team can explain why these responsibilities belong together

For example, a pricing service may reasonably contain:

• price calculation rules
• discount application logic
• pricing policy validation
• pricing-specific read models

Those concerns change together and revolve around one coherent capability.

Weak cohesion often looks different:

• unrelated rules live together because they were convenient to deploy
• one team cannot explain why several workflows share the same boundary
• parts of the service use different domain language that rarely overlaps
• one section mostly exists to support another service’s needs

What Coupling Looks Like in Practice

Coupling is not the same as any communication at all. Healthy services still collaborate. The problem is excessive or routine dependency. High coupling often shows up as:

• many synchronous calls for ordinary workflows
• strong release coordination between supposedly independent teams
• one service needing deep knowledge of another service’s data shape
• consumer-driven API expansion that leaks provider internals

This is why coupling has both runtime and organizational forms. A service can be tightly coupled even if the APIs are technically separate.

Boundary Tension as a Review Tool

Boundary tension becomes visible when the service is carrying conflicting signals such as:

• high internal model confusion
• high external chattiness
• unclear ownership
• frequent incident spillover across services
• repeated exceptions to the intended contract

One practical scorecard can help make this concrete:

 1service: checkout
 2cohesion_signals:
 3  coherent_business_language: medium
 4  shared_change_drivers: low
 5coupling_signals:
 6  synchronous_dependencies_per_request: high
 7  release_coordination_with_other_teams: high
 8operational_signals:
 9  incident_bounce_rate: medium-high
10boundary_tension: high
11review_bias: redesign-contracts-or-redraw-boundary

What this demonstrates:

• tension can be evaluated from several angles
• the result guides architectural review, not just measurement
• a service may need different remedies depending on where the tension comes from

High Cohesion With Moderate Coupling Can Still Be Fine

Not every service needs zero coupling. A cohesive service may still depend on a few authoritative neighbors. For example:

• checkout may synchronously ask payment for authorization
• fulfillment may depend on warehouse integration
• entitlement service may depend on identity or policy evaluation

The issue is not dependency itself. The issue is whether the dependency is proportionate and meaningful. A few clear business interactions are different from a long chain of low-level remote lookups.

Low Cohesion and High Coupling Is the Worst Combination

The most dangerous case is when:

• the service does not have a strong internal center
• and it still coordinates heavily with neighbors

That usually means the service is too small, too layered, or too politically shaped. It carries neither a strong internal model nor clean external independence. This is the point where “microservice” becomes mostly packaging.

Use Tension to Choose the Right Response

The right response depends on where the stress is coming from:

• high internal confusion may justify splitting
• high external chattiness may justify merging or contract redesign
• ownership confusion may require team-boundary review
• contract sprawl may require read models or better API shaping

That is why boundary tension is a decision aid rather than a single conclusion.

Design Review Question

An inventory service owns stock reservation, warehouse synchronization, low-stock alerts, supplier replenishment hints, and a batch export API for reporting. The same service also participates in several synchronous workflows and requires frequent cross-team contract changes. What should the review ask first?

The review should first determine where the tension is strongest. If the core inventory model is still cohesive but external coordination is the main problem, the first fix may be contract redesign or read models. If the internal domain itself is confused and the change drivers diverge sharply, a split may be justified. The key is not to jump to “split” or “merge” before understanding whether the dominant stress is internal or external.

Quiz Time