Dependency Inversion
Dependency Inversion richtet wichtige Fachlogik auf stabile, eigene Verträge aus. Technische Adapter erfüllen diese Verträge und hängen damit vom Fachkern ab.
- Eigener VertragDer Fachkern definiert, was er braucht.
- AdapterSetzt den Vertrag technisch um und ist austauschbar.
- RichtungDer Quellcode zeigt von der Technik zum Fachkern.
Einordnung
Warum das wichtig ist
Hängt die Zahlungslogik direkt von der Anbieter-API ab, zieht jede Änderung des Anbieters sie mit; auch Tests brauchen den echten Anbieter. Dependency Inversion ist das Prinzip, Dependency Injection nur ein Mechanismus. Fremde Begriffe übersetzt der Baustein ACL.
Dieser Baustein erklärt die Richtung technischer Abhängigkeiten. Für die fachliche Übersetzung fremder Modelle siehe Anti-Corruption Layer.
Auf einen Blick · Adapter hängen vom Fachkern ab
Abhängigkeit zum Zahlungsanbieter umkehren
Das Zahlungsmodul benötigt die Fähigkeit, einen Betrag zu autorisieren. Es definiert dafür einen eigenen Vertrag; ein Adapter übersetzt ihn zum externen Zahlungsanbieter.
So liest du das Bild
- Eigener Vertrag Der Kasten Zahlung autorisieren im Bereich Fachkern.
- Adapter Anbieteradapter und Testadapter implementieren denselben Vertrag; der Adapter ruft den Zahlungsanbieter auf.
- Richtung Im Bild „So kehrt sich die Richtung um“ kreuzt der Pfeil die Grenze nachher nach innen, vorher nach außen.
Breites Diagramm · bei Bedarf seitlich verschieben
Diagramm als Text lesen
- Zahlungslogik: fachliche Status (Fachkern)
- Zahlung autorisieren: eigener Vertrag (Fachkern)
- Anbieteradapter: übersetzt Aufruf und Antwort (Technik)
- Zahlungsanbieter: externe API (Extern)
- Testadapter: vorhersagbare Antworten (Test)
- Zahlungslogik → Zahlung autorisieren: verwendet
- Anbieteradapter → Zahlung autorisieren: implementiert
- Anbieteradapter → Zahlungsanbieter: ruft auf
- Testadapter → Zahlung autorisieren: implementiert
So kehrt sich die Richtung um
- Zahlungslogikfachliche Regeln und StatusZahlungslogik kennt SDK-Typen Anbieter-API.
- Anbieter-APIfremdes SDK, fremde Typen
Die Abhängigkeit zeigt von innen nach außen über die Grenze; jede Anbieteränderung trifft die Zahlungslogik.
Nutzen & Grenzen
Hilft, wenn
- Fachliche Regeln sind eng an konkrete Datenbank- oder Netzwerkbibliotheken gebunden.
- Ein unabhängiger Test oder der Austausch einer Infrastrukturkomponente ist ein belegtes Ziel.
Grenzen
- Ein zusätzlicher Vertrag kostet Implementierung und Pflege. Prüfe seinen Nutzen anhand von Modulgrenzen und tatsächlichen Test- oder Austauschbedürfnissen.
- Ein technisch benannter Vertrag kann die Fachlogik weiterhin an Infrastruktur binden. Verwende fachliche Sprache und halte Separation of Concerns zwischen Regel und technischer Wirkung klar.
In der Praxis
- Konkrete Abhängigkeit lokalisieren. Ermittle, welche Infrastrukturbegriffe in der Fachlogik auftauchen und Tests erschweren. Das Ergebnis zeigt, ob ein Vertrag einen realen Kopplungspunkt lösen kann.
- Benötigte Fähigkeit als Vertrag ausdrücken. Formuliere eine fachliche Operation mit klaren Eingaben und Ergebnissen. Platziere sie im Kern und orientiere die Abhängigkeit an Modulgrenzen.
- Adapter und unabhängigen Test ergänzen. Implementiere den Vertrag an der Infrastrukturgrenze und prüfe das Fachverhalten mit einer kontrollierten Umsetzung. Hexagonale Architektur bietet dafür eine passende Strukturperspektive.
Ausführliche Erklärung lesen
Die Umkehrung richtet Abhängigkeiten so aus, dass die Fachlogik benötigte Verträge vorgibt und technische Adapter konkrete Bibliotheken anbinden. Dependency Inversion richtet den Quellcode stattdessen auf einen Vertrag aus, der die benötigte Fähigkeit fachlich beschreibt. Adapter implementieren diesen Vertrag außerhalb des Kerns. Hexagonale Architektur ordnet Ports und Adapter; Separation of Concerns trennt Änderungsgründe.
Zur Laufzeit kann der Kern weiterhin die technische Umsetzung aufrufen, während der Quellcode vom Adapter zum Kernvertrag zeigt. So lässt sich Fachverhalten unabhängig testen. Schnittstellen sollten jedoch einen echten Austausch- oder Testnutzen bieten; übermäßige Abstraktion vergrößert die Zahl der Konzepte ohne entsprechenden Gewinn.
Drei Begriffe werden oft verwechselt. Dependency Inversion ist das Prinzip: Die Fachlogik hängt von eigenen Abstraktionen ab, nicht von konkreter Technik. Dependency Injection ist ein Mechanismus: Der passende Adapter wird von außen hereingereicht, zum Beispiel durch ein Framework wie Spring. Inversion of Control ist das Oberkonzept: Das Framework ruft deinen Code auf, nicht umgekehrt. Wichtig: Injection ohne Inversion bringt nichts. Wird etwa das Anbieter-SDK direkt in die Zahlungslogik injiziert, zeigt die Abhängigkeit weiterhin nach außen; nur das Beschaffen des Objekts hat sich geändert.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
In welche Richtung kreuzt der Pfeil die Grenze vorher und nachher?
Lösung mit Begründung ansehen
Vorher zeigt er von der Zahlungslogik (innen) zur Anbieter-API (außen). Nachher zeigt er vom Anbieteradapter (außen) zum Vertrag (innen).
AnwendenAuf eine neue Lage übertragen
Im Test soll die Zahlung von B-1042 ohne echten Anbieter durchlaufen. Wie gehst du vor?
Lösung mit Begründung ansehen
Du setzt den Testadapter ein. Er erfüllt denselben Vertrag und liefert vorhersagbare Antworten; die Zahlungslogik bleibt unverändert.
BewertenEine Alternative abwägen
Das Team injiziert das Anbieter-SDK per Spring direkt in die Zahlungslogik und nennt das Dependency Inversion. Stimmt das?
Lösung mit Begründung ansehen
Nein. Das ist Injection ohne eigene Abstraktion: Die Zahlungslogik kennt weiterhin SDK-Typen, die Abhängigkeit zeigt nach außen. Inversion entsteht erst, wenn der Fachkern einen eigenen Vertrag definiert und der Adapter ihn erfüllt.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Microsoft · Architectural Principles (öffnet in neuem Tab)Erklärt Separation of Concerns, Kapselung und Dependency Inversion.
- Alistair Cockburn · Hexagonal Architecture (öffnet in neuem Tab)Originalbeschreibung von Ports, Adaptern und austauschbaren Außenanbindungen.
- Martin Fowler · Inversion of Control Containers and the Dependency Injection pattern (öffnet in neuem Tab)Grenzt Inversion of Control und Dependency Injection voneinander ab.