Skip to content
Software Architecture Guide

Reduce Coupling

Explanation

Section titled “Explanation”

Coupling describes how much modules depend on each other. When coupling is high, change is contagious. You touch one module, and the modules that depend on it break.

Reducing coupling is one of two levers for modifiability, meaning how easily a system accepts change. The other lever is raising cohesion inside a module. See Increase Cohesion and Coupling and Cohesion.

A tactic is a design decision that affects how well an architecture reaches a quality goal. It does this by adjusting the parameters of a quality model. Tactics for modifiability build on three ideas: coupling, cohesion and cost. The Reduce Coupling tactics adjust the coupling parameter.

One concrete move is to abstract common services. Several modules may have similar dependencies. You hide them behind one shared contract. Dependents then rely on the contract and not on each separate dependency.

The goal is that a change stays local, so fewer modules feel it.

Example

Section titled “Example”

Three modules in a shop system each talk to a different notification service. Each module has its own way of calling it. Replacing one service forces edits in its module.

The team defines one shared contract for sending a notification. The three modules call only that contract. A single place maps the contract to each service. Now a change to one service touches that place and not the three modules.

Trade-offs

Section titled “Trade-offs”

The supplied facts do not describe the costs of these tactics. They do say that modifiability tactics weigh coupling, cohesion and cost together. Judge each tactic against its cost before you apply it. See Choosing and Applying Tactics and Tactic Trade-off Balancing.

Several similar dependencies hidden behind one shared contract.

Diagram source 
flowchart LR
  subgraph Before
    A1[Module A] --> S1[Service 1]
    B1[Module B] --> S2[Service 2]
    C1[Module C] --> S3[Service 3]
  end
  subgraph After
    A2[Module A] --> K[Shared contract]
    B2[Module B] --> K
    C2[Module C] --> K
    K --> T1[Service 1]
    K --> T2[Service 2]
    K --> T3[Service 3]
  end

Checks

Section titled “Checks”
  • The document explains which modules depend on a module that is expected to change often.
  • Similar dependencies on a common service are hidden behind one shared contract.
  • The document states that the tactic is chosen to lower coupling between modules for modifiability.
Section titled “Related”

Sources

Section titled “Sources”