Zum Hauptinhalt springen

Infrastruktur-Abstraktionen (Ports)

Einleitung​

Ports entkoppeln Geschäftslogik von Infrastruktur.

Der Anwendungskern definiert stabile Verträge (Ports), gegen die er arbeitet.
Konkrete Technologien (DB, Broker, HTTP-Clients) werden über Adapter angebunden.

Ziel:

Die Domäne bleibt stabil – Infrastruktur darf wechseln.

Einordnung

Ports sind ein Strukturprinzip in Hexagonal-, Clean- und Onion-Architekturen.

Sie gehören zur Applikations- und Domänenschicht, nicht zur Infrastruktur.

Ports definieren:

  • was die Anwendung braucht
  • nicht wie es technisch umgesetzt wird

Grundprinzip

Kernidee:

  • Core kennt nur den Port
  • Adapter implementiert den Port
  • Infrastruktur bleibt austauschbar

Arten von Ports

1️⃣ Inbound Ports (Driving)​

  • definieren Use Cases
  • werden von Controllern, Messaging-Listenern etc. aufgerufen

Beispiel:

CreateOrderUseCase

2️⃣ Outbound Ports (Driven)​

  • definieren benötigte Infrastruktur-Fähigkeiten
  • werden vom Core aufgerufen

Beispiel:

OrderRepository
PaymentGateway
EventPublisher

Charakteristika

  • Ports sind fachlich benannt, nicht technisch
  • Keine Framework-Typen im Port
  • Adapter enthalten Technologie-Code
  • Tests mocken Ports, nicht Infrastruktur

Vorteile

  • Sehr hohe Testbarkeit
  • Schnelle Feedback-Zyklen
  • Technologiewechsel ohne Core-Refactoring
  • Klare Trennung von Verantwortung

Risiken / typische Fallstricke

1️⃣ Technische Ports​

Wenn Ports so aussehen:

JpaRepository
KafkaTemplate
HttpClientWrapper

→ Architektur ist bereits kompromittiert.

2️⃣ Overabstraction​

Wenn keine Austauschbarkeit realistisch ist:

→ unnötige Interfaces erhöhen Komplexität.

3️⃣ Inkonsistente Schnitte​

Unterschiedliche Module definieren Ports nach verschiedenen Prinzipien.

→ Erosion der Architektur.

Wann sinnvoll?

  • Langfristig wartbare Business-Logik
  • Wechselbare Infrastruktur
  • Hohe Testanforderungen
  • Komplexe Domänen

Wann weniger sinnvoll?

  • Kleine CRUD-App
  • Kurzlebiges Projekt
  • Monolith ohne Integrationsdruck

Strategische Perspektive

Ports sind kein Selbstzweck.

Sie sind ein Schutzmechanismus für:

  • Domänenlogik
  • Architektur-Stabilität
  • langfristige Evolvierbarkeit

Richtig eingesetzt:

Infrastruktur ist Detail. Domäne ist Zentrum.

Typische Kombinationen

  • Hexagonal Architecture als Strukturrahmen
  • Outbox/Repository als Outbound Ports
  • REST-Controller als Inbound Adapter
  • Contract-Tests zwischen Core und Adapter

Fazit

Ports ermöglichen:

  • klare Architekturgrenzen
  • testbare Business-Logik
  • kontrollierte Technologie-Evolution

Sie sind der Kernmechanismus, der Clean/Hexagonal Architektur tatsächlich wirksam macht.