Zum Hauptinhalt springen

Hexagonal Architecture (Ports & Adapters)

Einleitung​

Hexagonal Architecture isoliert die Business-Logik konsequent von Infrastruktur, UI und externen Systemen.

Die Anwendung besteht aus:

  • einem Core (Domäne + Use Cases)
  • Ports als stabile Verträge
  • Adaptern, die Technologie anbinden

Ziel:

Der Core bleibt stabil – Infrastruktur ist austauschbares Detail.

Einordnung

Hexagonal Architecture ist ein App-internes Strukturmuster.

Sie ist:

  • kein Systemstil
  • kein Deployment-Muster
  • kein Infrastruktur-Pattern

Sie strukturiert ausschließlich den inneren Aufbau einer Anwendung.

Zentrales Prinzip

Externe Systeme sprechen nie direkt mit dem Core.
Sie sprechen immer über Ports.

Grundstruktur

Arten von Ports

1️⃣ Inbound Ports (Driving)​

Definieren:

  • Use Cases
  • Anwendungsfälle
  • Interaktionspunkte

Beispiele:

  • CreateOrderUseCase
  • CalculatePremium

Sie werden von:

  • REST-Controllern
  • CLI
  • Messaging-Listenern

aufgerufen.

2️⃣ Outbound Ports (Driven)​

Definieren:

  • benötigte Infrastruktur-Fähigkeiten

Beispiele:

  • OrderRepository
  • PaymentGateway
  • EventPublisher

Sie werden vom Core aufgerufen.

Charakteristika

  • Core kennt nur Ports
  • Adapter implementieren Ports
  • Keine Framework-Typen im Core
  • Mehrere Adapter pro Port möglich (Mock, InMemory, DB, HTTP etc.)

Symmetrie-Gedanke

Hexagonal behandelt:

  • UI
  • Datenbank
  • Messaging
  • Externe Services

als gleichwertige Außensysteme.

Es gibt kein „oben“ oder „unten“ – nur innen und außen.

Das ist der eigentliche Kern des Hexagon-Gedankens.

Vorteile

  • Sehr hohe Testbarkeit
  • Technologieaustausch ohne Core-Refactoring
  • Klare Architekturgrenzen
  • Geringere Framework-Abhängigkeit

Risiken / typische Fallstricke

1️⃣ Technische Ports​

Wenn Ports technische Details enthalten:

→ Architektur verletzt.

2️⃣ Übergranularität​

Zu viele Ports für triviale Funktionen → unnötige Komplexität.

3️⃣ Adapter-Logik-Leakage​

Wenn Business-Logik in Adapter wandert → Core wird ausgehöhlt.

Wann sinnvoll?

  • Komplexe Domänen
  • Langlebige Systeme
  • Hohe Testanforderungen
  • Wechselbare Infrastruktur

Wann weniger sinnvoll?

  • Kleine CRUD-App
  • Kurzlebige Tools
  • Geringe Business-Logik

Abgrenzung zu Clean Architecture

HexagonalClean Architecture
Fokus auf Ports & AdapterFokus auf Dependency Rule
Symmetrische AußenweltKlare Schichtenstruktur
Core + PortsEntities + Use Cases + Adapters

Clean Architecture kann als Weiterentwicklung / Formalisierung der Hexagonal-Idee verstanden werden.

Strategische Perspektive

Hexagonal Architecture schützt:

  • Domäne
  • Testbarkeit
  • Evolvierbarkeit

Sie reduziert:

  • Framework-Lock-in
  • Infrastruktur-Kopplung

Sie erhöht:

  • Strukturdisziplin
  • Abstraktionsbedarf

Fazit

Hexagonal Architecture ist besonders stark, wenn:

Business-Logik wertvoller ist als Technologie.

Sie ist kein Selbstzweck, aber ein sehr wirksames Strukturprinzip für langlebige Systeme.

Quellen

  • Alistair Cockburn: Hexagonal Architecture, 2005.
  • arc42 Patterns Collection.