Kopplung und Kohäsion

Zwei Maße für Struktur

Kopplung ist der Grad, in dem ein Modul von einem anderen abhängt, sodass eine Änderung am einen eine Änderung am anderen erzwingen kann. Kohäsion ist der Grad, in dem die Elemente innerhalb eines Moduls zusammengehören, weil sie einem einzigen Zweck dienen. Beide Ideen führte Larry Constantine Ende der 1960er-Jahre im Rahmen der Structured-Design-Bewegung ein; veröffentlicht wurden sie 1974 im Artikel Structured Design von Wayne Stevens, Glenford Myers und Constantine im IBM Systems Journal und dann ausführlicher in Edward Yourdons und Constantines Buch Structured Design (1979). Abschnitt 0.3 hat sie informell eingeführt; dieser Abschnitt macht sie präzise.

Beide hängen zusammen. Wenn die Dinge, die sich gemeinsam ändern, im selben Modul liegen (hohe Kohäsion), überqueren weniger Änderungen Modulgrenzen, und die Module müssen weniger voneinander wissen (geringe Kopplung). Yourdon und Constantine gingen so weit zu sagen, dass in der Praxis die Kohäsion die wichtigere der beiden sei. Die Änderbarkeitstaktiken in Abschnitt 2.6 (Kohäsion erhöhen, Kopplung verringern) beruhen genau auf diesem Paar.

Gleich zu Beginn eine Klarstellung: Kopplung ist kein Mangel. Ein System, dessen Module nie voneinander abhingen, würde nichts Nützliches tun. Martin Fowler warnte 2001 in einem Beitrag zu diesem Thema, dass der Versuch, Kopplung ganz zu beseitigen, alles nur in ein riesiges Modul schiebt, in dem die Kopplung verborgen statt verschwunden ist. Das Ziel ist, Kopplung bewusst zu wählen: wenige Abhängigkeiten, über schmale und stabile Schnittstellen, in sinnvolle Richtungen und so schwach, wie es die Aufgabe erlaubt.

Die Stufen der Kopplung

Structured Design ordnete die Arten, wie zwei Module verbunden sein können, von der schädlichsten bis zur harmlosesten. Die unten gezeigte Form mit sechs Stufen wird meist auf Glenford Myers’ Bücher zum Composite Design Mitte der 1970er-Jahre zurückgeführt und später von Meilir Page-Jones bekannt gemacht; Namen und Abgrenzungen unterscheiden sich zwischen den Quellen leicht, aber dies ist die Form, die man in den meisten Lehrbüchern findet. Definiert wurden die Stufen für Prozeduren innerhalb eines Programms, doch jede hat eine direkte Entsprechung zwischen Komponenten und Services, und dort begegnen sie Architekturfachleuten heute.

Zwei Warnungen. Erstens ist die Skala ein Wegweiser für Risiken, kein Gesetz. Stempelkopplung ist oft eine vernünftige Abwägung: Ein ganzes Objekt zu übergeben ist einfacher, als sechs Felder auszupacken, und der Preis ist nur, dass der Empfänger jetzt brechen kann, wenn Felder geändert werden, die er gar nicht nutzt. Zweitens sagt die Skala nichts darüber, wie viele Abhängigkeiten es gibt oder wie oft sich die andere Seite ändert. Ein einzelner kontrollgekoppelter Aufruf an ein Modul, das sich nie ändert, kann harmlos sein; Datenkopplung an ein Modul, das sich wöchentlich ändert, kann schmerzen. Später in diesem Kapitel bietet Connascence ein feineres Vokabular, und Vlad Khononovs Balancing Coupling in Software Design (2024) argumentiert, dass die Stärke der Kopplung immer zusammen mit der Distanz zwischen den Modulen und ihrer Volatilität beurteilt werden sollte.

# 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)

Die Stufen der Kohäsion

Kohäsion fragt, warum die Elemente eines Moduls zusammen sind. Yourdon und Constantine beschrieben sieben Arten der Zusammengehörigkeit, wieder von der schlechtesten zur besten. Die unteren Stufen gruppieren Dinge aus Gründen, die nichts mit dem Problem zu tun haben (sie wurden zufällig zur selben Zeit geschrieben oder laufen im selben Moment); die oberen Stufen gruppieren Dinge, weil sie mit denselben Daten oder auf denselben einzelnen Zweck hin arbeiten. Spätere Lehrbuchzusammenfassungen sind sich in der groben Rangfolge einig: Zufällige und logische Kohäsion sind schlecht, kommunikative und sequenzielle sind gut und funktionale ist am besten, wobei die Abstände zwischen den Stufen nicht gleichmäßig sind.

Auf Architekturebene ist Kohäsion die Frage, ob eine Komponente oder ein Service einen einzigen Daseinsgrund hat. Ein Service namens CustomerService, der Anmeldung, Treuepunkte und Marketingeinstellungen verwaltet, ist bestenfalls logisch kohäsiv: Drei Teams werden ihn aus drei voneinander unabhängigen Gründen ändern. Eine gute Faustregel ist, den Zweck eines Moduls in einem Satz zu beschreiben, ohne und zu verwenden; Abschnitt 3.5 entwickelt das zum Single Responsibility Principle weiter, das über die Personen definiert ist, die Änderungen anfordern.

Afferente und efferente Kopplung

Die obigen Stufen beschreiben die Art einer Abhängigkeit. Architekturfachleute müssen Abhängigkeiten außerdem zählen. Afferente Kopplung (Ca) ist die Anzahl der Module außerhalb einer Komponente, die von ihr abhängen: ihre eingehenden Pfeile. Efferente Kopplung (Ce) ist die Anzahl der Module außerhalb der Komponente, von denen sie abhängt: ihre ausgehenden Pfeile. Die Begriffe stammen aus der Anatomie, wo afferente Nerven Signale hinein- und efferente Nerven sie hinausleiten. Robert C. Martin definierte sie 1994 für Pakete, indem er Klassen zählte; heutige Werkzeuge zählen Klassen, Module oder Pakete, prüfen Sie also immer, was ein Werkzeug zählt, bevor Sie Zahlen vergleichen.

Die beiden Zahlen erzählen unterschiedliche Geschichten. Eine Komponente mit hohem Ca, etwa eine gemeinsame money-Bibliothek, die von vierzig Modulen genutzt wird, ist verantwortlich: Jede Änderung an ihr kann viele andere brechen, also muss sie sich vorsichtig und selten ändern. Eine Komponente mit hohem Ce, etwa ein Checkout-Workflow, der Preisgestaltung, Lagerbestand, Zahlung, Lieferung und Benachrichtigungen aufruft, ist exponiert: Sie muss sich unter Umständen immer dann ändern, wenn sich eine davon ändert. Keins von beiden ist an sich falsch; das Problem entsteht, wenn eine Komponente stark von anderen genutzt wird und selbst von vielen volatilen Dingen abhängt. Abschnitt 3.4 macht aus Ca und Ce Martins Instabilitätsmetrik und die darauf aufbauenden Regeln.

Kopplung in verteilten Systemen

Wenn Module zu Services werden, die über ein Netzwerk kommunizieren, gelten die klassischen Stufen weiter, aber drei weitere Arten von Kopplung treten in den Vordergrund. Keine davon ist in einer Funktionssignatur sichtbar, weshalb Teams, die ein System in Services aufteilen, oft überrascht sind, wie stark gekoppelt die Services noch sind.

Zeitliche Kopplung bedeutet, dass ein Teil nur funktioniert, wenn ein anderer im selben Moment verfügbar ist und antwortet. Ein synchroner HTTP-Aufruf von Checkout an Zahlungen koppelt ihre Verfügbarkeit: Fällt Zahlungen aus, fällt auch der Checkout aus, und die gemeinsame Verfügbarkeit ist das Produkt der beiden (Abschnitt 2.5). Asynchrone Nachrichten über eine Queue beseitigen das, um den Preis von letztlich statt sofort vorliegenden Ergebnissen. (Im Design auf Code-Ebene bedeutet derselbe Begriff manchmal, dass Aufrufe in einer festen Reihenfolge erfolgen müssen, etwa open() vor read(); der Kontext macht die Bedeutung meist klar.)

Deployment-Kopplung bedeutet, dass zwei Teile gemeinsam oder in einer festen Reihenfolge ausgeliefert werden müssen, weil eine Änderung am einen den anderen bricht. Wenn jedes Release des Bestellmoduls ein gleichzeitiges Release der Abrechnung braucht, sind die beiden in der Praxis eine deploybare Einheit, was auch immer das Diagramm sagt. Abwärtskompatible Änderungen, versionierte APIs und das Expand-and-Contract-Muster sind die üblichen Heilmittel.

Semantische Kopplung bedeutet, dass sich zwei Teile über eine Bedeutung einig sein müssen, die keine Schnittstelle ausdrückt: dass eine Bestellung mit status = 4 versandt ist, dass Preise in Pence angegeben sind und die Mehrwertsteuer enthalten, dass ein „aktiver Kunde“ in den letzten 90 Tagen bestellt hat. Solche Übereinkünfte brechen lautlos, wenn eine Seite ihre Auslegung ändert. Das Heilmittel ist, die Bedeutung im Vertrag explizit zu machen (benannte Zustände, Einheiten in Feldnamen, veröffentlichte Schemas) oder die Regel an einer Stelle zu halten, die andere fragen.

Taktiken zur Verringerung von Kopplung

Schmale Schnittstellen. Legen Sie nur die wenigsten Operationen und Felder offen, die Clients brauchen. Jedes zusätzliche Feld in einer API-Antwort ist etwas, von dem ein Client abhängig werden kann (Abschnitt 3.3 zu Hyrums Gesetz). Vermittler. Setzen Sie etwas zwischen die beiden Parteien, damit keine die Details der anderen kennt: einen Adapter oder Anti-Corruption Layer, der das Modell eines Lieferanten übersetzt, ein API-Gateway oder einen Message Broker, der Sender und Empfänger zeitlich und in ihrer Identität entkoppelt. Ereignisse statt Befehle. Ein Befehl (Abrechnung, erstelle eine Rechnung) zwingt den Sender, den Empfänger und dessen Aufgabe zu kennen; ein Ereignis (eine Bestellung wurde aufgegeben) lässt den Sender eine Tatsache feststellen und beliebig viele Empfänger reagieren, sodass sich neue Consumer hinzufügen lassen, ohne den Producer zu ändern. Datenhoheit. Jedes Datum hat einen Eigentümer, der es schreibt; andere Module fragen den Eigentümer über seine Schnittstelle oder halten eine eigene, über Ereignisse gespeiste Kopie und lesen nie die Tabellen des Eigentümers (Abschnitt 7.1).

Jede Taktik hat ihren Preis. Vermittler fügen einen Sprung hinzu und etwas, das zusätzlich betrieben werden muss. Ereignisse geben die sofortige Konsistenz auf und machen den Ablauf eines Geschäftsprozesses schwerer an einer Stelle zu überblicken. Kopien von Daten können veraltet sein. Datenhoheit bedeutet, APIs zu bauen und zu versionieren, die eine gemeinsame Tabelle umsonst geliefert hat. Die Abwägung lohnt sich dort, wo Änderungen häufig oder Teams getrennt sind, und oft nicht zwischen zwei Klassen, die eine einzige Person pflegt.

Ausgearbeitetes Beispiel: ein eng gekoppeltes Paar aus Bestellung und Abrechnung refaktorisieren

Das Modul Bestellungen eines Onlineshops ruft bei jeder aufgegebenen Bestellung direkt das Modul Abrechnung auf. Die Abrechnung liest dann die Bestelltabelle, um die Details zu ermitteln, interpretiert die numerischen Codes der Statusspalte und berechnet die Mehrwertsteuer aus den Positionspreisen neu. Der folgende Code ist eine vereinfachte Fassung; er zeigt drei der Probleme auf einmal.

# 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)

Jede Änderung am Aufbau der Bestelltabelle, an den Statuscodes oder an den Mehrwertsteuerregeln muss nun in beiden Modulen gleichzeitig erfolgen. Bestellungen kann keine Bestellung annehmen, wenn die Abrechnung langsam ist oder ausfällt. Und die beiden Verhalten der Abrechnung werden über ein Flag ausgewählt, das Bestellungen kennen muss. Das Refactoring verläuft in vier Schritten: Bestellungen ruft die Abrechnung nicht mehr auf, sondern veröffentlicht ein OrderPlaced-Ereignis, das genau die Fakten enthält, die die Abrechnung braucht, einschließlich der Summen, die Bestellungen bereits berechnet hat; die Abrechnung abonniert es und erfasst Rechnungen in einem eigenen Speicher; die beiden Verhalten werden zu zwei Operationen; und die Bestelltabelle wird privat für Bestellungen.

# 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): ...

Wie Fachleute diese Ideen nutzen

Erfahrene Designer nennen die Namen der Stufen in Reviews selten, wenden sie aber ständig an: Sie hinterfragen jeden Flag-Parameter, suchen nach gemeinsamen Tabellen und globalem Zustand, fragen nach dem einen Zweck jedes Moduls und beobachten, welche Module sich in der Versionskontrolle gemeinsam ändern. An den Grenzen zwischen Teams und Services sind sie streng, weil Kopplung dort teuer aufzulösen ist; innerhalb eines kleinen Moduls, das einer Person gehört, sind sie gelassen, weil sie dort billig ist.

Außerdem machen sie Kopplung sichtbar. Ein aus dem Code erzeugter Abhängigkeitsgraph, eine Zählung von Ca und Ce pro Komponente und eine Liste der Datenbanktabellen, auf die mehr als ein Service zugreift, gehören zu den aufschlussreichsten Sichten auf eine Architektur, und alle lassen sich automatisch erzeugen und im Build verfolgen. Der nächste Abschnitt wendet sich dem Prinzip zu, das Kopplung von vornherein schwach hält: Entscheidungen hinter Schnittstellen verbergen.