Hexagonale Architektur
Hexagonale Architektur schützt Fachlogik hinter selbst definierten Ports. Adapter übersetzen zwischen diesen Verträgen und konkreten Technologien.
- PortVom Kern definierter, fachlich benannter Vertrag.
- Eingehend und ausgehendEingehende Adapter rufen den Kern, ausgehende ruft er.
- TestbarkeitTest-Adapter ersetzen jede Infrastruktur.
Einordnung
Warum das wichtig ist
Der Fachkern bleibt frei von Technik, die Adapter lassen sich austauschen. Der Nutzen liegt vor allem in der Testbarkeit und in mehreren Zugängen zum selben Kern. Dependency Inversion erklärt, warum Pfeile nach innen zeigen, die ACL, was an der Grenze übersetzt wird; hier geht es um die Gesamtform.
Dieser Baustein erklärt Ports und Adapter rund um einen Fachkern. Für die allgemeine Abhängigkeitsrichtung siehe Dependency Inversion.
Auf einen Blick · Kern im Sechseck mit Ports
Adapter tauschen, Kern bleibt
Das interne Zahlungsmodul des modularen Monolithen entscheidet über Zahlungszustände. Ein Anbieteradapter übersetzt seinen Port in die externe API.
So liest du das Bild
- Port Die apricot Chips „Zahlung beauftragen“, „Anbieter belasten“ und „Zahlung speichern“ am Sechseck.
- Eingehend und ausgehend Links der eingehende Port mit seinen Adaptern, rechts die zwei ausgehenden.
- Testbarkeit Sind alle Test-Adapter gewählt, erscheint das Badge und der Kern bleibt unverändert.
eingehend (driving, primär)Zahlung beauftragen
ausgehend (driven, sekundär)Anbieter belasten
ausgehend (driven, sekundär)Zahlung speichern
Änderungen am Fachkern: 0
Betriebsfall: Alle Ports sind mit echten Adaptern verbunden, der Kern arbeitet unverändert.
Nutzen & Grenzen
Hilft, wenn
- Ports halten den Kern unabhängig von Adaptern, sodass fachliche Regeln ohne Infrastruktur prüfbar bleiben.
- Ein gemeinsamer Anwendungsvertrag verbindet mehrere Eingangs- oder Ausgangswege, während Adapter ihre Protokolle übersetzen.
- Ein fachlicher Port kapselt technische Formate und Fehler und hält Anbieter austauschbar.
Grenzen
- Testdoppel ersetzen keinen echten Anbieter: Serialisierung und Fehlerverhalten brauchen weiterhin Integrationstests.
- Port-Inflation: Ein Port für jede Kleinigkeit kostet mehr, als er schützt.
- Technische Typen im Port binden den Kern weiter an die Infrastruktur.
In der Praxis
- Formuliere Ports in fachlichen Fähigkeiten und beschreibe erwartete Ergebnisse sowie Fehler. Technische Bibliotheks- und Speichertypen bleiben in den Adaptern, damit der Kern unabhängig bleibt.
- Halte Adapter für Übersetzung und technische Kommunikation zuständig. Prüfe, ob derselbe Kern mit mehreren Eingangs- oder Ausgangsadaptern denselben fachlichen Vertrag erfüllt.
- Teste Kern und reale Adapter an ihren jeweiligen Grenzen. Dependency Inversion vertieft die Abhängigkeitsrichtung; Modulgrenzen klären die fachliche Zuordnung.
Ausführliche Erklärung lesen
Ein Port beschreibt eine Anwendungsein- oder -ausgabe aus fachlicher Sicht. Adapter übersetzen zwischen diesem Vertrag und technischen Protokollen oder Speichern. Der Anwendungskern kennt benötigte Fähigkeiten; Adapter übernehmen die Anbindung konkreter Bibliotheken, Datenbanken und Transportformen.
Eingehende Adapter starten Anwendungsfälle; ausgehende Adapter erfüllen deren Abhängigkeiten. Die Trennung erleichtert Tests und Austausch, sofern ein Port eine echte Grenze darstellt. Technische Typen im Port würden die Kopplung lediglich in eine Schnittstelle verschieben.
Dependency Inversion erklärt, wie der Kern benötigte Fähigkeiten vorgibt; Modulgrenzen zeigen, wo solche Verträge fachliche Zuständigkeiten verbinden.
Verwandte Formen heißen Clean Architecture und Onion Architecture. Sie teilen die Kernidee: Abhängigkeiten zeigen nach innen, der Fachkern kennt keine Technik.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Du wählst „Test-Double“ und „In-Memory“, lässt aber „Web-Checkout“ stehen. Was zeigt das Bild, und was zählt „Änderungen am Fachkern“?
Lösung mit Begründung ansehen
Eine gemischte Konstellation. Der Zähler bleibt bei 0, weil nur Adapter gewechselt wurden.
AnwendenAuf eine neue Lage übertragen
Ein nächtlicher Abgleichjob soll offene Zahlungen erneut beauftragen. Was ergänzt du?
Lösung mit Begründung ansehen
Einen weiteren eingehenden Adapter, den Job, für den Port „Zahlung beauftragen“. Fachkern und Port bleiben unverändert.
BewertenEine Alternative abwägen
Das Team testet nur noch mit Test-Double und In-Memory. Reicht das?
Lösung mit Begründung ansehen
Vorteil: schnelle, stabile Tests der Fachregeln. Nachteil: Serialisierung, Fehlerverhalten des Anbieters und Datenbankverhalten bleiben ungeprüft. Empfehlung: Fachtests mit Doubles beibehalten und ergänzend wenige Integrationstests gegen echten Anbieter und echte Datenbank.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Alistair Cockburn · Hexagonal Architecture (öffnet in neuem Tab)Originalbeschreibung von Ports, Adaptern und austauschbaren Außenanbindungen.
- Microsoft · Common Web Application Architectures (öffnet in neuem Tab)Vergleicht Schichten und Clean Architecture einschließlich Abhängigkeitsrichtung.
- Microsoft · Architectural Principles (öffnet in neuem Tab)Erklärt Separation of Concerns, Kapselung und Dependency Inversion.