Orientierung

Die Workbench im Überblick

Beginne mit deiner Arbeitssituation, nicht mit einem Kapitel. Die Workbench verbindet einen geführten Ablauf mit dem nötigen Fachwissen, einem ausführbaren Beispiel und dem Nachweis, dass die Änderung sicher ist. Nutze die Seite für eine konkrete Engineering-Aufgabe: Kläre zuerst Ziel und Risiko und halte danach Ergebnis, Nachweis und nächsten Schritt fest.

Arbeitsablauf wählen Bedienung und Arbeitsweise

Arbeitsmodell

So greifen die Bereiche ineinander

1 · Führen

Arbeitsabläufe

Sie strukturieren Feature, Incident, API-, Datenbank- oder Modernisierungsarbeit vom Auftrag bis zum Nachweis.

Passenden Ablauf wählen

2 · Vertiefen

Themenwissen

Deep Dives liefern Entscheidungen, Beispiele, Checkpoints und Lieferobjekte genau dort, wo der Ablauf Fachwissen braucht.

Zu den sechs Themenclustern

3 · Erproben

Projekte und Labs

Referenzprojekte zeigen zusammenhängende Lösungen; Labs machen Architektur- und Codeentscheidungen praktisch überprüfbar.

Referenzprojekte öffnen

4 · Absichern

Evidence und Betrieb

Tests, Produktionsreife, Observability und Runbooks belegen, dass die Änderung auslieferbar und im Fehlerfall beherrschbar ist.

Produktionsreife prüfen

Schnellwahl

Wo steige ich ein?

Situation	Erster Einstieg	Erwartetes Ergebnis
Ich habe einen konkreten Änderungsauftrag.	Arbeitsabläufe	Geschnittener Plan mit Risiken, Umsetzung und Nachweis.
Ich muss eine technische Entscheidung treffen.	Architektur	Verglichene Optionen und eine nachvollziehbare Entscheidung.
Ich brauche ein zusammenhängendes Codebeispiel.	Referenzprojekte	Ausführbare Lösung mit Tests und dokumentierten Grenzen.
Ein System ist instabil oder nicht produktionsreif.	Runbooks	Stabilisierung, Diagnose und überprüfbarer Betriebsnachweis.
Ich kenne die Workbench noch nicht.	Geführter Einstieg	Kurze Route zu den wichtigsten Arbeitsflächen.

Vertiefung

Sechs Themencluster

Entwicklung

Java Engineering

Dieser Cluster verbindet moderne Java-Sprachmittel mit frameworkfreier Fachlogik, Spring-Adaptern und einem reproduzierbaren Build. Ziel ist nicht möglichst viel Framework, sondern verständlicher Code mit kontrolliertem Laufzeitverhalten.

Typische Fragen

Wo gehört eine fachliche Regel hin?
Welche Spring-Grenze hält die Domain testbar?
Wie werden JVM-Annahmen gemessen statt vermutet?

Lieferobjekte

Getesteter Domain-Code, klare Ports, reproduzierbarer Build, Laufzeitmessung und dokumentierte Pattern-Entscheidung.

Empfohlene Reihenfolge

Java & JVM → Spring Enterprise → Maven & Build → Design Patterns.

Deep Dives

Entwurf

Domäne & Architektur

Hier wird aus einem Geschäftsproblem ein tragfähiger Systementwurf. Der Cluster verbindet Sprache und Invarianten mit Modulgrenzen, Schnittstellen und nachvollziehbaren Architekturentscheidungen.

Typische Fragen

Wer besitzt eine Entscheidung und die zugehörigen Daten?
Welche Konsistenz ist fachlich wirklich erforderlich?
Wann rechtfertigt ein Problem einen eigenen Service?

Lieferobjekte

Ubiquitous Language, Context Map, Invarianten, ADR, API- oder Event-Vertrag und überprüfbare Architekturregel.

Empfohlene Reihenfolge

DDD → Architecture Workbench → API Design → Messaging & Events.

Deep Dives

Daten

Daten & Integration

Der Cluster behandelt Daten als fachliche Verantwortung, nicht nur als Tabellen oder Nachrichten. Er verbindet Transaktionsgrenzen, Schemaevolution, Datenqualität und verlässliche Integration über Systemgrenzen hinweg.

Typische Fragen

Welche Daten müssen atomar konsistent bleiben?
Wie entwickelt sich ein Schema ohne Big Bang?
Wie werden Duplikate, Reihenfolge und Replay beherrscht?

Lieferobjekte

Datenmodell, Migration, Transaktionskonzept, versionierter Vertrag, Reconciliation und Replay-Nachweis.

Empfohlene Reihenfolge

Persistence → Schnittstellenverträge → Event-Verarbeitung → Referenzprojekt.

Deep Dives

Qualität

Qualität & Änderung

Qualität entsteht hier als Risikokontrolle über den gesamten Änderungsweg. Tests, Reviews und Refactoring werden so gewählt, dass sie eine konkrete Fehlermöglichkeit erkennen und eine sichere Weiterentwicklung ermöglichen.

Typische Fragen

Welcher Fehler hätte den größten fachlichen Schaden?
Welche Testart liefert dafür die schnellste Evidenz?
Wie bleibt ein Umbau in kleinen Schritten reversibel?

Lieferobjekte

Risikobasierter Testplan, Review-Befunde, Charakterisierungstests, Refactoring-Schritte und Abnahmekriterien.

Empfohlene Reihenfolge

Testing → Code Review → Refactoring → Legacy Modernization.

Deep Dives

Produktion

Delivery & Betrieb

Dieser Cluster führt eine Änderung vom reproduzierbaren Artefakt bis zum stabilen Produktionsbetrieb. Delivery, Plattform, Telemetrie, Performance und Security werden als ein gemeinsamer Schutzmechanismus behandelt.

Typische Fragen

Welche Gates müssen vor dem Rollout nachweisbar sein?
Woran erkennen wir früh, dass ein Release schadet?
Wie stabilisieren, diagnostizieren und rollen wir zurück?

Lieferobjekte

Pipeline Evidence, Deployment Guardrails, SLI/SLO, Dashboard, Runbook, Performance-Budget und Threat Review.

Empfohlene Reihenfolge

CI/CD → Cloud & Kubernetes → Observability → Performance → Security.

Deep Dives

Arbeitsweise

Senior Practice

Senior Practice verbindet technische Arbeit mit Ownership, Kommunikation und überprüfbaren Entscheidungen. Der Cluster hilft, unklare Aufträge zu schneiden und mehrere Rollen auf ein gemeinsames Ergebnis auszurichten.

Typische Fragen

Was ist das eigentliche Ziel und wer entscheidet?
Welche Teams, Risiken und Abhängigkeiten sind betroffen?
Welche Evidence beendet die Diskussion belastbar?

Lieferobjekte

Change Brief, Entscheidungsnotiz, Owner-Matrix, Arbeitsplan, Review-Protokoll und klarer nächster Schritt.

Empfohlene Reihenfolge

Developer Cockpit → Geführter Workflow → Senior Engineering → Referenzprojekt.

Deep Dives

End-to-End

Sechs echte Praxisfälle

Java Engineering · Liefertermin validieren

Ausgangslage

Im Order-Service darf ein Liefertermin weder in der Vergangenheit noch außerhalb des vertraglich erlaubten Zeitfensters liegen. Die Regel steckt bisher gleichzeitig im Controller und im Datenbankskript.

Entscheidung und Umsetzung

Die Regel wird als fachlicher Werttyp in die frameworkfreie Domain verschoben. Spring übernimmt nur HTTP-Übersetzung; Maven erzwingt die Modulgrenze.

JAVA

public record DeliveryDate(LocalDate value) {
    public DeliveryDate {
        requireNonNull(value, "value");
        if (value.isBefore(LocalDate.now())) {
            throw new PastDeliveryDate(value);
        }
    }
}

Fehlerfall und Nachweis

Zeitzonen und Tageswechsel werden mit einer injizierten Clock getestet. Unit-Test, Controller-Test und Architekturtest müssen bestehen; die API liefert einen stabilen Fehlercode statt einer Java-Exception.

Ergebnis: eine fachliche Regel, ein Implementierungsort und reproduzierbare Tests.

Domäne & Architektur · Bestellung stornieren

Ausgangslage

Eine Bestellung darf nach Versand nicht mehr storniert werden. Order, Payment und Shipping gehören verschiedenen Teams und besitzen unterschiedliche Daten.

Entscheidung und Trade-off

Order bleibt Owner der Stornierungsentscheidung. Shipping veröffentlicht den Versandstatus; Payment reagiert nach akzeptierter Stornierung mit einer Erstattung. Eine synchrone Kette wird vermieden, dafür muss die Oberfläche den Zwischenzustand sichtbar machen.

Umsetzung

Invariante und Begriffe mit Product klären.
API-Fehlervertrag und Ereignisse versionieren.
ADR mit synchroner und asynchroner Alternative festhalten.
Idempotenz und verspätete Events testen.

Nachweis

Contract-Tests, Sequenzdiagramm, ADR, Metrik für ausstehende Erstattungen und ein Runbook für hängen gebliebene Vorgänge.

Ergebnis: klare Ownership ohne verteilte Transaktion.

Daten & Integration · Event-Vertrag erweitern

Ausgangslage

OrderPlaced.v1 benötigt ein optionales Lieferfenster. Drei Consumer deployen unabhängig; historische Events müssen weiterhin abspielbar bleiben.

Vorgehen

Consumer und gespeicherte Schemas inventarisieren.
Feld optional mit eindeutiger Semantik ergänzen.
Tolerant Reader und Default-Verhalten testen.
Producer zuerst rückwärtskompatibel ausrollen.
Replay mit Produktionsbeispielen in einer isolierten Umgebung prüfen.

Fehlerfall

Ein Consumer interpretiert „nicht gesetzt“ als ganztägige Lieferung. Diese Annahme wird im Vertrag dokumentiert und als Consumer-Contract-Test gesichert.

Nachweis und Rückbau

Schema-Kompatibilitätsbericht, Contract-Tests, Lag-Metrik und Rollback auf den alten Producer. Das neue Feld bleibt beim Rückbau lesbar.

Ergebnis: evolvierbarer Vertrag ohne Big-Bang-Deployment.

Qualität & Änderung · Rabattlogik refaktorieren

Ausgangslage

Eine 180-zeilige Methode berechnet Rabatte, prüft Berechtigungen und schreibt Auditdaten. Es gibt nur zwei langsame End-to-End-Tests.

Sicherungsnetz

Reale Grenzfälle werden als Charakterisierungstests festgehalten: Standardkunde, Premiumkunde, abgelaufene Kampagne, Maximalrabatt und fehlende Berechtigung.

Kleine Schritte

Audit-Schreiben hinter einen Port verschieben.
Berechtigungsprüfung extrahieren.
Rabattregeln als benannte Strategien modellieren.
Nach jedem Schritt Tests und Mutation Score prüfen.

Review und Ergebnis

Das Review bewertet Verhaltensgleichheit, neue Abhängigkeiten und Verständlichkeit. Performance wird vor und nach dem Umbau gemessen.

Ergebnis: dieselbe Fachlichkeit mit isoliert testbaren Regeln und geringerem Änderungsrisiko.

Delivery & Betrieb · Latenz nach Deployment

Symptom

Nach Release 4.18 steigt die p95-Latenz des Checkout-Endpunkts von 280 ms auf 1,9 s. Fehlerrate und CPU bleiben zunächst unauffällig.

Stabilisierung

Der Rollout wird gestoppt, Traffic auf die vorige Revision verschoben und das Error Budget geschützt. Erst danach beginnt die Ursachenanalyse.

Evidenz und Ursache

Trace-Vergleich vor und nach dem Release.
Neue synchrone Inventory-Abfrage als längsten Span identifizieren.
Connection-Pool-Sättigung mit Metriken bestätigen.
Hypothese durch Lasttest reproduzieren.

Dauerhafte Korrektur

Batch-Abfrage statt N+1-Aufrufen, Timeout-Budget, Pool-Alarm und Performance-Regressionstest. Das Runbook erhält Diagnoseabfrage und Rollback-Kriterium.

Ergebnis: p95 unter 350 ms und ein messbares Schutznetz gegen Wiederholung.

Senior Practice · Kundenlöschung koordinieren

Ausgangslage

Eine Datenschutzanforderung betrifft Identity, Orders, Billing, Analytics und Backups. „Datensatz löschen“ reicht wegen Aufbewahrungspflichten und Audit nicht aus.

Führung und Entscheidung

Product, Legal, Security, DBA und die Service-Owner definieren gemeinsam Löschung, Anonymisierung, Sperrung und Nachweis je Datenklasse. Ein Owner verantwortet den Gesamtfluss.

Lieferplan

Datenlandkarte und Rechtsgrundlage je System.
Idempotenter Löschauftrag mit Statusmodell.
Dry Run und Freigabe für kritische Daten.
Dashboard für Restbestände und fehlgeschlagene Schritte.
Abnahme mit nachvollziehbarer Evidence.

Ergebnis

Eine dokumentierte Entscheidung, klare Verantwortlichkeiten, ein wiederholbarer Prozess und ein prüfbarer Nachweis statt manueller Einzelaktionen.

Im Alltag

Starte im passenden Cluster. Wechsle erst dann in eine Fachseite, wenn die Aufgabe eine tiefere technische Entscheidung, Umsetzung oder Prüfung verlangt.