Kopplung
Kopplung beschreibt, wie stark ein Baustein von Details eines anderen abhängt. Abhängigkeiten übertragen Änderungen und Ausfälle entlang ihrer Beziehungen.
- DetailkopplungKennt interne Tabellen und Status.
- VertragSchmale, fachliche Schnittstelle.
- KopplungsartenDaten, Format, Zeit, Auslieferung, Bedeutung.
Einordnung
Warum das wichtig ist
Je mehr ein Baustein über die Innereien eines anderen weiß, desto weiter wirken Änderungen und Ausfälle. Ein Umbau an der Bestellung bricht dann die Rechnung. Wo Module ihre Grenzen ziehen, behandelt der Baustein Modulgrenzen.
Dieser Baustein erklärt Beziehungen zwischen Bausteinen. Für den inneren Zusammenhalt eines Bausteins siehe Kohäsion.
Auf einen Blick · Vertrag statt Detailzugriff
Kopplung zwischen Bestellung und Rechnung
Das Rechnungsmodul benötigt Bestellnummer, Rechnungsadresse und Gesamtbetrag. Es soll weder interne Bestelltabellen lesen noch den vollständigen Warenkorb kennen.
So liest du das Bild
- Detailkopplung Bei Detailkopplung steht die Rechnung auf „bricht“, sobald das Schema der Bestellung wechselt.
- Vertrag Bei Vertragskopplung kennt die Rechnung nur Bestellnummer, Adresse und Betrag und bleibt stabil.
- Kopplungsarten Die Tabelle zeigt fünf Arten im Shop und je einen Hebel zum Lockern.
- stabilBestellungTabellen unverändert
- gekoppeltRechnungsdaten-Vertragkein Vertrag, Rechnung greift direkt zu
- gekoppeltRechnungliest interne Bestelltabellen
Tabellen und StatusBekanntes Wissen
Die Rechnung läuft, kennt aber interne Tabellen und Status der Bestellung. Jede spätere Änderung dort betrifft sie.
Fünf Arten, wie der Shop gekoppelt ist
| Art | Im Shop | So lockerst du sie |
|---|---|---|
| Daten | Rechnung liest die Tabellen der Bestellung direkt. | Eigener Vertrag, klare Modulgrenzen, Datenhoheit bei der Bestellung. |
| Format | Alle Module teilen dasselbe Bestellformat. | Eigene Modelle je Modul, Übersetzung im Bounded Context oder per ACL. |
| Zeit | Bestellung wartet synchron auf die Zahlung. | Nicht auf alles warten: Bestellung annehmen, Zahlung als „Klärung läuft“ nachziehen. |
| Auslieferung | Alle Module gehen mit einem Release live. | Nur bei belegtem Bedarf trennen, etwa als Microservice. |
| Bedeutung | Alle müssen wissen, was ein Statuswert bedeutet. | Fachliche Begriffe im Vertrag festhalten, Ubiquitous Language. |
Nutzen & Grenzen
Hilft, wenn
- Änderungen in einem Baustein erfordern regelmäßig koordinierte Anpassungen an mehreren Stellen.
- Teams benötigen unabhängige Lieferungen und müssen versteckte Release- oder Datenabhängigkeiten erkennen.
Grenzen
- Lose Kopplung hat einen Preis: mehr Verträge zu pflegen, mehr Indirektion und bei asynchroner Entkopplung verteilte Fehlerfälle. Lockere dort, wo Änderungen tatsächlich durchschlagen, und halte die Komplexität im Blick.
- Vollständige Isolation verkompliziert nötige Zusammenarbeit. Ziel ist eine klare, stabile Abhängigkeit, etwa ein schmaler API-Vertrag, nicht das Verbot jeder Beziehung. Stärke nur die relevanten Modulgrenzen.
In der Praxis
- Abhängigkeiten in mehreren Formen erfassen. Sammle Aufrufe, Datenzugriffe, gemeinsame Formate und zeitliche Erwartungen. Das Ergebnis macht direkte und indirekte Bindungen sichtbar.
- Eine typische Änderung durch den Graphen verfolgen. Notiere betroffene Bausteine, Teams und Releases. Verknüpfe die Befunde mit Modulgrenzen, um private Details von stabilen Verträgen zu unterscheiden.
- Datenbesitz und Vertrag klären. Bestimme, wer ein Schema ändern darf und wie Verbraucher neue Fassungen übernehmen. Datenhoheit hilft, gemeinsame Tabellenzugriffe und ihre Folgen gezielt einzuordnen.
- Kopplungsdimensionen am Rechnungsablauf prüfen. Notiere Annahmen zu Schema, Bedeutung, Zeit und Reihenfolge. Kläre insbesondere, ob ein Betrag netto oder brutto gemeint ist und welche Änderung gemeinsame Releases auslösen würde. Nutze die Befunde zur Prüfung der Modulgrenzen.
Ausführliche Erklärung lesen
Abhängigkeiten können Aufrufe, geteilte Daten, gemeinsame Formate, zeitliche Reihenfolgen oder abgestimmte Releases betreffen. Je mehr Annahmen Verbraucher über interne Entscheidungen eines anderen Bausteins treffen, desto weiter reichen Änderungen. Modulgrenzen definieren kontrollierte Zugriffe; Kohäsion ordnet zusammengehörige Aufgaben innerhalb eines Bausteins.
Zusammenarbeit zwischen Bausteinen bleibt notwendig. Ziel ist eine klare, stabile und verantwortete Abhängigkeit, nicht vollständige Isolation. Prüfe deshalb Änderungsfolgen, Fehlerverhalten und Datenbesitz. Der tatsächliche Ablauf macht auch indirekte Kopplung über gemeinsame Datenbanken oder Betriebsannahmen sichtbar.
Gregor Hohpe beschreibt Kopplung als mehrdimensional. Ein Rechnungsworker kann zeitweise ausfallen, während Bestellungen weiter angenommen werden. Die Beteiligten teilen weiterhin Annahmen zu Schema, Bedeutung und gegebenenfalls Reihenfolge. Ein Feld „Betrag“ kann bei gleichem Zahlenformat netto oder brutto meinen. Zeitliche Entkopplung und semantische Kompatibilität müssen daher getrennt geprüft werden.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Wie viele Module sind betroffen, wenn die Bestellung ihr Schema ändert und ein Vertrag besteht?
Lösung mit Begründung ansehen
Nur die Bestellung. Die Rechnung bleibt stabil, weil der Rechnungsdaten-Vertrag gleich bleibt.
AnwendenAuf eine neue Lage übertragen
Bestellung ruft Zahlung synchron auf und wartet. Welche Art von Kopplung ist das, und wie lockerst du sie?
Lösung mit Begründung ansehen
Zeitkopplung: Bestellung ist vom Ergebnis der Zahlung abhängig, solange sie wartet. Lockern lässt sie sich asynchron, etwa mit einem Auftrag und einer späteren Antwort. Dafür nimmst du verteilte Fehlerfälle in Kauf.
BewertenEine Alternative abwägen
Die Rechnung soll zur Vereinfachung direkt Bestelltabellen lesen. Wie wägst du ab?
Lösung mit Begründung ansehen
Vorteil: weniger Code für die Übergabe. Nachteil: Schemaänderungen der Bestellung brechen die Rechnung, und es braucht gemeinsame Datenbanktests statt eines Vertragstests. Bei begrenztem Nutzen überwiegt der Preis.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Parnas · On the Criteria To Be Used in Decomposing Systems into Modules (öffnet in neuem Tab)Klassischer Aufsatz (1972): Module verbergen Entwurfsentscheidungen, damit Änderungen lokal bleiben.
- Connascence.io · Arten der Kopplung (öffnet in neuem Tab)Katalog der Connascence-Arten, mit denen sich Kopplung nach Stärke und Reichweite einordnen lässt.
- Lieber · Law of Demeter: Principle of Least Knowledge (öffnet in neuem Tab)Offizielle Seite zum Gesetz von Demeter: Ein Objekt spricht nur mit seinen direkten Nachbarn.
- Gregor Hohpe · The Many Facets of Coupling (öffnet in neuem Tab)Unterscheidet mehrere Dimensionen der Kopplung, darunter zeitliche und semantische Abhängigkeiten.