Coupling and cohesion

Two measures of structure

Coupling is the degree to which one module depends on another, so that a change to one can force a change to the other. Cohesion is the degree to which the elements inside one module belong together because they serve a single purpose. Both ideas were introduced by Larry Constantine in the late 1960s as part of the structured design movement and published in the 1974 IBM Systems Journal paper Structured Design by Wayne Stevens, Glenford Myers and Constantine, then at greater length in Edward Yourdon and Constantine's book Structured Design (1979). Section 0.3 introduced them informally; this section makes them precise.

The two are linked. If the things that change together live in the same module (high cohesion), then fewer changes cross module boundaries, and the modules need to know less about each other (low coupling). Yourdon and Constantine went as far as saying that, in practice, cohesion was the more important of the two. The modifiability tactics in Section 2.6 (increase cohesion, reduce coupling) rest on exactly this pair.

One clarification at the start: coupling is not a defect. A system whose modules never depended on each other would do nothing useful. Martin Fowler, writing on the subject in 2001, warned that trying to remove coupling entirely only pushes everything into one huge module where the coupling is hidden rather than gone. The aim is to choose coupling deliberately: few dependencies, through narrow and stable interfaces, pointing in sensible directions, and as weak as the job allows.

The levels of coupling

Structured design ranked the ways two modules can be connected, from the most damaging to the most benign. The six-level form below is usually traced to Glenford Myers's books on composite design in the mid-1970s and was later popularised by Meilir Page-Jones; names and boundaries vary slightly between sources, but this is the form found in most textbooks. They were defined for procedures in one program, but each has a direct equivalent between components and services, which is where architects meet them today.

Two cautions. First, the scale is a guide to risk, not a law. Stamp coupling is often a sensible trade: passing a whole object is simpler than unpacking six fields, and the cost is only that the receiver may now break when fields it does not even use are changed. Second, the scale says nothing about how many dependencies there are or how often the other side changes. A single control-coupled call to a module that never changes may be harmless; data coupling to a module that changes weekly may hurt. Later in this chapter, connascence offers a finer vocabulary, and Vlad Khononov's Balancing Coupling in Software Design (2024) argues that the strength of coupling should always be judged together with the distance between the modules and how volatile they are.

# Control coupling: the caller chooses the callee's internal branch
def handle_payment(order, mode):
    if mode == "charge":
        ...  # call the provider, store the transaction
    elif mode == "refund":
        ...  # look up the transaction, reverse it
    elif mode == "dry_run":
        ...  # validate only

handle_payment(order, "refund")

# Data coupling: separate operations, each taking only what it needs
def charge(order_id: str, amount_pence: int) -> str: ...
def refund(transaction_id: str, amount_pence: int) -> None: ...

refund("tx_81f2", 1999)

The levels of cohesion

Cohesion asks why the elements of a module are together. Yourdon and Constantine described seven kinds of association, again from worst to best. The lower levels group things for reasons unrelated to the problem (they happened to be written at the same time, or they run at the same moment); the higher levels group things because they work on the same data or towards the same single purpose. Later textbook summaries agree on the broad ranking: coincidental and logical cohesion are poor, communicational and sequential are good and functional is best, though the steps between levels are not evenly spaced.

At architecture scale, cohesion is the question of whether a component or service has one reason to exist. A service called CustomerService that handles login, loyalty points and marketing preferences is logically cohesive at best: three teams will change it for three unrelated reasons. A good heuristic is to describe a module's purpose in one sentence without using and; Section 3.5 develops this as the single responsibility principle, defined in terms of the people who request changes.

Afferent and efferent coupling

The levels above describe the kind of a dependency. Architects also need to count them. Afferent coupling (Ca) is the number of modules outside a component that depend on it: its incoming arrows. Efferent coupling (Ce) is the number of modules outside it that it depends on: its outgoing arrows. The terms come from anatomy, where afferent nerves carry signals in and efferent nerves carry them out. Robert C. Martin defined them for packages in 1994 by counting classes; tools today count classes, modules or packages, so always check what a tool is counting before comparing numbers.

The two numbers tell different stories. A component with high Ca, such as a shared money library used by forty modules, is responsible: any change to it can break many others, so it must change carefully and rarely. A component with high Ce, such as a checkout workflow that calls pricing, stock, payment, delivery and notifications, is exposed: it may need to change whenever any of those change. Neither is wrong in itself; the problem arises when a component is both heavily depended upon and itself depends on many volatile things. Section 3.4 turns Ca and Ce into Martin's instability metric and the rules built on it.

Coupling in distributed systems

When modules become services that talk over a network, the classic levels still apply, but three further kinds of coupling become prominent. None of them is visible in a function signature, which is why teams that split a system into services are often surprised by how coupled the services still are.

Temporal coupling means that one part works only if another is available and responsive at the same moment. A synchronous HTTP call from Checkout to Payments couples their availability: if Payments is down, so is checkout, and the combined availability is the product of the two (Section 2.5). Asynchronous messages through a queue remove this, at the cost of eventual rather than immediate results. (In code-level design the same term sometimes means that calls must happen in a fixed order, such as open() before read(); context usually makes the meaning clear.)

Deployment coupling means that two parts must be released together, or in a fixed order, because a change in one breaks the other. If every release of Orders needs a simultaneous release of Billing, the two are one deployable unit in practice, whatever the diagram says. Backward-compatible changes, versioned APIs and the expand-and-contract pattern are the usual cures.

Semantic coupling means that two parts must agree on meaning that no interface expresses: that an order with status = 4 is shipped, that prices are in pence and include VAT, that an 'active customer' has ordered in the last 90 days. Such agreements break silently when one side changes its interpretation. The cure is to make the meaning explicit in the contract (named states, units in field names, published schemas) or to keep the rule in one place that others ask.

Tactics to reduce coupling

Narrow interfaces. Expose the fewest operations and fields that clients need. Every extra field in an API response is something a client may come to depend on (Section 3.3 on Hyrum's law). Intermediaries. Put something between the two parties so neither knows the other's details: an adapter or anti-corruption layer that translates a supplier's model, an API gateway, or a message broker that decouples sender from receiver in time and in identity. Events instead of commands. A command (Billing, create invoice) makes the sender know the receiver and its job; an event (an order was placed) lets the sender state a fact and lets any number of receivers react, so new consumers can be added without changing the producer. Data ownership. Each piece of data has one owner that writes it; other modules ask the owner through its interface or keep their own copy fed by events, never reading the owner's tables (Section 7.1).

Every tactic has a price. Intermediaries add a hop and something else to run. Events give up immediate consistency and make the flow of a business process harder to see in one place. Copies of data can be stale. Data ownership means building and versioning APIs that a shared table gave you for free. The trade-off is worth making where change is frequent or teams are separate, and often not worth making between two classes that one person maintains.

Worked example: refactoring a tightly coupled order and billing pair

An online shop's Orders module calls Billing directly whenever an order is placed. Billing then reads the orders table to find the details, interprets the status column's numeric codes and recalculates VAT from the line prices. The code below is a simplified version; it shows three of the problems at once.

# orders.py
def place_order(basket, customer_id):
    order_id = db.insert("orders", customer_id=customer_id, status=1,
                         lines=basket.lines)
    billing.process(order_id, mode="invoice")   # Orders waits for Billing
    return order_id

# billing.py
def process(order_id, mode):
    row = db.query_one("SELECT * FROM orders WHERE id = %s", order_id)
    if row["status"] != 1:              # 1 means 'placed', by convention
        return
    net = sum(l["price"] * l["qty"] for l in row["lines"])
    vat = round(net * 0.2)               # VAT rule duplicated here
    if mode == "invoice":
        db.insert("invoices", order_id=order_id, net=net, vat=vat)
    elif mode == "credit_note":
        db.insert("credit_notes", order_id=order_id, net=-net, vat=-vat)

Any change to the orders table's layout, to the status codes or to the VAT rules now has to be made in both modules at once. Orders cannot accept an order if Billing is slow or failing. And Billing's two behaviours are selected by a flag that Orders must know about. The refactoring proceeds in four steps: Orders stops calling Billing and instead publishes an OrderPlaced event carrying exactly the facts Billing needs, including the totals Orders has already calculated; Billing subscribes and records invoices in its own store; the two behaviours become two operations; and the orders table becomes private to Orders.

# orders.py
def place_order(basket, customer_id):
    order = Order.create(customer_id, basket)      # computes net and VAT once
    repository.save(order)
    events.publish("OrderPlaced", {
        "schema_version": 1, "order_id": order.id,
        "customer_id": customer_id,
        "net_pence": order.net_pence, "vat_pence": order.vat_pence})
    return order.id

# billing.py
@events.subscribe("OrderPlaced")
def on_order_placed(event):
    create_invoice(event["order_id"], event["net_pence"], event["vat_pence"])

def create_invoice(order_id, net_pence, vat_pence): ...
def create_credit_note(order_id, net_pence, vat_pence): ...

How professionals use these ideas

Experienced designers rarely quote the names of the levels in reviews, but they apply them constantly: they question every flag parameter, look for shared tables and global state, ask what each module's one purpose is, and watch which modules change together in version control. At the boundaries between teams and services they are strict, because coupling there is expensive to unwind; inside one small module owned by one person they are relaxed, because there it is cheap.

They also make coupling visible. A dependency graph generated from the code, a count of Ca and Ce per component and a list of database tables accessed by more than one service are among the most informative views of an architecture, and all can be produced automatically and tracked in the build. The next section turns to the principle that keeps coupling weak in the first place: hiding decisions behind interfaces.