Senior Java · Fachbereich

Architecture Workbench

Architekturformen, Qualitätsattribute, Abhängigkeitsregeln und nachvollziehbare Entscheidungen. Nutze die Seite vor einer technischen Entscheidung: Vergleiche Optionen und Auswirkungen und halte anschließend Entscheidung, Trade-offs und Überprüfungspunkt fest.

Zur Übersicht

Arbeitsauftrag

Wann verwenden?

Wenn eine Entscheidung mehrere Module, Teams oder Qualitätsziele langfristig beeinflusst.

Nicht dafür verwenden

Nicht für lokale Implementierungsdetails, die leicht reversibel sind.

Definition of Done

Kontext, Optionen und Trade-offs sind als ADR dokumentiert; Auswirkungen, Owner, Review-Termin und Evidence sind benannt.

Architektur als überprüfbare Regeln formulieren

Trade-offs anhand von Qualitätsattributen bewerten

Entscheidungen chronologisch nachvollziehbar halten

Architekturform wählen

Form	Stärke	Kosten	Warnsignal
Modularer Monolith	einfache Transaktionen und Lieferung	gemeinsamer Release	Module umgehen ihre Grenzen
Services	unabhängige Ownership und Skalierung	verteilte Daten und Betrieb	jede Klasse wird zum Service
Event-driven	entkoppelte Reaktionen und Erweiterbarkeit	eventuelle Konsistenz und Replay	Events tragen nur technische CRUD-Daten

Hexagonale Architektur mit Domäne, Application und Adaptern

Alle Kapitel

Architekturtreiber

Architektur entsteht aus fachlicher Komplexität, Qualitätsanforderungen, Teamstruktur und Betriebsbedingungen. Ein Diagramm ohne diese Treiber ist nur eine Momentaufnahme.

Qualitätsattribute werden als Szenarien formuliert: Auslöser, Umgebung, betroffene Komponente und messbare Reaktion.

TEXT

Szenario: Verfügbarkeit
Auslöser: Pricing-Service ist 30 Sekunden nicht erreichbar
Umgebung: normale Last
Reaktion: Auftrag wird mit nachvollziehbarem Status angenommen
Messgröße: keine verlorenen Aufträge, Recovery unter 5 Minuten

Hexagonale Struktur

Die Domäne definiert Ports. Adapter implementieren technische Details. Abhängigkeitsrichtung zeigt nach innen.

Das Ziel ist nicht maximale Anzahl von Interfaces, sondern kontrollierte Veränderbarkeit und testbare Grenzen.

TEXT

domain <- application <- inbound adapters
                  ^
                  |
             outbound ports
                  ^
                  |
          database / messaging adapters

Architecture Decision Record

Eine gute Entscheidung beschreibt Kontext, Entscheidung, Alternativen, Konsequenzen und Überprüfungszeitpunkt. Sie dokumentiert nicht nur das Ergebnis, sondern die damalige Wissenslage.

MARKDOWN

## ADR: Outbox für OrderPlaced
Status: angenommen
Kontext: Datenbankzustand und Kafka-Nachricht müssen zuverlässig gekoppelt sein.
Entscheidung: Transaktionale Outbox mit separatem Publisher.
Alternativen: Dual Write, verteilte Transaktion.
Konsequenzen: zusätzliche Tabelle, Monitoring und Wiederholungslogik.

Praxisartefakt · ADR-Auszug

Kontext: Billing benötigt eigene Skalierung, besitzt aber noch keine unabhängige Datenhoheit.
Entscheidung: Billing bleibt Modul; Extraktion wird nicht begonnen.
Alternative: Service mit synchronem Zugriff auf Order-Daten wurde wegen verteilter Kopplung verworfen.
Konsequenz: Gemeinsamer Release bleibt, Modulgrenze wird per Fitness Function geschützt.
Review-Signal: Eigenes Team und separater Datenlebenszyklus.