- Tag 1 · SysteminventurAkteure, externe Systeme, Hauptprozesse und zentrale Begriffe erfassen.Nachweis: Eine Context Map mit maximal zwölf Elementen.
- Tag 2 · Capability MapOrder, Pricing, Payment, Billing, Delivery und Notification fachlich abgrenzen.Nachweis: Capabilities mit Verantwortungen und Eigentümern.
- Tag 3 · Modul- und DatenkarteModule, Datenbesitz, synchrone Aufrufe und Events markieren.Nachweis: Container-/Modulkarte mit Data Ownership.
- Tag 4 · Kritischer GeschäftsprozessBestellung bis Rechnung als End-to-End-Ablauf verfolgen.Nachweis: Sequence Diagram auf Systemebene.
- Tag 5 · BetriebsblickDeployment, Datenbank, Messaging, Logs, Metrics und Fehlerpfade einordnen.Nachweis: Operations View mit fünf wichtigsten Risiken.
- Tag 6 · Teach-backDas komplette System ohne Unterlagen in 15 Minuten erklären.Nachweis: Audio-/Notizprotokoll und drei erkannte Wissenslücken.
Selbstprüfung
Warum startet der Lernweg nicht mit Klassen?
Weil zuerst fachlicher Zweck, Systemgrenzen und Verantwortungen sichtbar sein müssen.
Was zeigt Data Ownership?
Welches Modul Daten fachlich besitzt und über Änderungen entscheiden darf.
Was ist das wichtigste Ergebnis?
Eine verständliche, einseitige Gesamtsicht des Referenzsystems.
Java und Maven als Lieferkette
Technisch + Build
- Tag 1 · Java-VersionenJava-11/17/21-Funktionen auswählen, die im Kernsystem echten Nutzen bringen.Nachweis: Entscheidungsmatrix mit fünf Sprachfeatures.
- Tag 2 · Maven-ReaktorParent, Module, interne Abhängigkeiten und Build-Reihenfolge untersuchen.Nachweis: Reaktor- und Moduldiagramm.
- Tag 3 · Dependency ManagementVersionen, BOMs, Scopes und transitive Abhängigkeiten erklären.Nachweis: Dependency-Policy für das Kernsystem.
- Tag 4 · Lifecycle und Pluginscompile, test, package, verify und install praktisch verfolgen.Nachweis: Lifecycle-Tabelle mit Plugin-Ausführung.
- Tag 5 · Qualitäts-GatesJUnit, JaCoCo, Checkstyle, SpotBugs und Sonar in der Kette positionieren.Nachweis: Quality-Gate-Pipeline.
- Tag 6 · RebuildEin kleines Mehrmodulprojekt aus dem Gedächtnis neu strukturieren.Nachweis: Lauffähiger Mini-Reaktor mit Tests.
Selbstprüfung
Warum gehört eine Version in dependencyManagement?
Damit Module konsistente Versionen verwenden, ohne jede Abhängigkeit zentral zu erzwingen.
Was unterscheidet package und verify?
verify führt zusätzliche Integritäts- und Qualitätsprüfungen nach dem Packaging aus.
Warum ist ein reproduzierbarer Build architekturrelevant?
Weil Lieferbarkeit, Sicherheit und Betrieb vom verlässlichen Artefakt abhängen.
DDD, Modulgrenzen und fachliche Verantwortung
Fachlich + Architektur
- Tag 1 · Ubiquitous LanguageBegriffe aus Order & Billing sammeln und widersprüchliche Bedeutungen finden.Nachweis: Glossar mit Kontextzuordnung.
- Tag 2 · Bounded ContextsOrder, Billing, Payment und Delivery als Verantwortungsräume schneiden.Nachweis: Context Map mit Beziehungen.
- Tag 3 · Aggregate und InvariantenKonsistenzregeln und Transaktionsgrenzen definieren.Nachweis: Aggregate-Steckbriefe.
- Tag 4 · Use-Case-TraceEinen Ablauf von API bis Persistenz und Integration verfolgen.Nachweis: Vier-Ebenen-Trace: Fachlich, Anwendung, Code, Infrastruktur.
- Tag 5 · KopplungsanalyseErlaubte, riskante und verbotene Abhängigkeiten markieren.Nachweis: Dependency Rules und Verletzungsliste.
- Tag 6 · ArchitekturgesprächModulgrenzen wie in einem Architecture Review verteidigen.Nachweis: ADR-Entwurf mit Trade-offs.
Selbstprüfung
Woran erkennt man eine sinnvolle Modulgrenze?
An klarer Verantwortung, eigenem Datenbesitz und wenigen stabilen Schnittstellen.
Warum sind Aggregate keine Tabellen-Gruppen?
Sie modellieren fachliche Konsistenz und Verhalten, nicht nur Datenstruktur.
Was verbindet Überblick und Detail?
Der Use-Case-Trace durch alle Ebenen.
Architekturstile und Trade-offs
Architektur + Strategie
- Tag 1 · Layered ArchitectureVerantwortungen, Abhängigkeitsrichtung und typische Erosion analysieren.Nachweis: Layer Map mit Regelverstößen.
- Tag 2 · Hexagonal ArchitecturePorts, Adapter und testbare Kernlogik am gleichen Use Case modellieren.Nachweis: Port-Adapter-Skizze.
- Tag 3 · Modular MonolithModule, interne APIs und Deployment-Einheit trennen.Nachweis: Modularitätsregeln.
- Tag 4 · MicroservicesTeamgrenzen, Datenautonomie und Betriebsaufwand ehrlich bewerten.Nachweis: Service-Schnitt mit Kostenliste.
- Tag 5 · VergleichAlle Stile nach Komplexität, Testbarkeit, Transaktionen, Betrieb und Migration vergleichen.Nachweis: Gewichtete Entscheidungsmatrix.
- Tag 6 · ADREine Zielarchitektur für Order & Billing begründen.Nachweis: Vollständiger Architecture Decision Record.
Selbstprüfung
Warum sind Microservices kein reines Code-Pattern?
Weil sie Organisation, Deployment, Daten, Betrieb und Kommunikation verändern.
Was ist ein Vorteil des modularen Monolithen?
Klare Modulgrenzen bei geringerem verteiltem Betriebsaufwand.
Was macht eine gute Architekturentscheidung aus?
Kontext, Alternativen, Trade-offs, Konsequenzen und überprüfbare Kriterien.
Spring und Jakarta EE im Verantwortungsmodell
Technisch + Runtime
- Tag 1 · Dependency InjectionLifecycle, Scopes, Proxies und Objektbesitz vergleichen.Nachweis: DI-Vergleich mit Laufzeitverantwortung.
- Tag 2 · REST und ValidationRequest-Mapping, Validierung und Fehlerübersetzung verfolgen.Nachweis: Request-Pipeline.
- Tag 3 · PersistenceJPA-Kontext, Repositories, Lazy Loading und N+1-Probleme einordnen.Nachweis: Persistence-Lifecycle-Karte.
- Tag 4 · TransaktionenBeginn, Commit, Rollback, Propagation und Grenzen untersuchen.Nachweis: Transaktions-Sequence.
- Tag 5 · Security und KonfigurationIdentity, Rollen, Secrets und externe Konfiguration zuordnen.Nachweis: Security Responsibility Map.
- Tag 6 · PortierungEinen kleinen Use Case konzeptionell von Spring nach Jakarta oder umgekehrt abbilden.Nachweis: Mapping-Tabelle mit unveränderten fachlichen Regeln.
Selbstprüfung
Was ist wichtiger als die konkrete DI-Annotation?
Lifecycle, Scope, Proxy-Verhalten und Verantwortlichkeit der Runtime.
Wo sollte eine fachliche Transaktion typischerweise beginnen?
Am Application Service beziehungsweise Use-Case-Einstieg.
Was bleibt beim Frameworkwechsel idealerweise stabil?
Domänenmodell, fachliche Regeln und Ports.
- Tag 1 · Lokale TransaktionenLocks, Isolation, Optimistic Locking und Rollback untersuchen.Nachweis: Transaktionsgrenzen pro Use Case.
- Tag 2 · Synchrone IntegrationREST/SOAP, Timeout, Fehlercodes und Rückwärtskompatibilität bewerten.Nachweis: Contract- und Failure-Matrix.
- Tag 3 · Asynchrone IntegrationEvents, Reihenfolge, Zustellung und Consumer-Verhalten analysieren.Nachweis: Event Flow.
- Tag 4 · Idempotenz und RetryDoppelte Nachrichten und Teilfehler kontrollierbar machen.Nachweis: Idempotency Design.
- Tag 5 · Outbox und SagaAtomare Veröffentlichung und lange Geschäftsprozesse modellieren.Nachweis: Outbox-/Saga-Sequenz.
- Tag 6 · Chaos WalkthroughZehn Ausfallpunkte simulieren und erwartetes Verhalten erklären.Nachweis: Failure Playbook.
Selbstprüfung
Warum löst Retry nicht jedes Problem?
Weil nicht-idempotente Operationen dupliziert und dauerhafte Fehler verstärkt werden können.
Was löst das Outbox Pattern?
Die atomare Verbindung zwischen Datenänderung und späterer Nachrichtenveröffentlichung.
Warum sind verteilte Prozesse selten eine ACID-Transaktion?
Weil unabhängige Systeme, Netzwerke und Laufzeiten keine gemeinsame zuverlässige Transaktionsgrenze bieten.
- Tag 1 · Legacy-InventurEJB, EAR, JNDI, SOAP, JMS, Stored Procedures und Security-Abhängigkeiten erfassen.Nachweis: Technische und fachliche Dependency Map.
- Tag 2 · Characterization TestsBestehendes Verhalten vor Änderungen sichtbar machen.Nachweis: Testset für Happy Path und Fehlerfälle.
- Tag 3 · ZielbildZielarchitektur und nicht-funktionale Anforderungen festlegen.Nachweis: Target Architecture Canvas.
- Tag 4 · MigrationsmusterStrangler, Branch by Abstraction, Anti-Corruption Layer und Parallel Run vergleichen.Nachweis: Pattern-Auswahl mit Begründung.
- Tag 5 · PilotmigrationEinen kleinen vertikalen Schnitt planen und Risiken absichern.Nachweis: Pilotplan mit Rollback.
- Tag 6 · AbnahmeFachliches Verhalten, Performance, Security und Betrieb vorher/nachher vergleichen.Nachweis: Abnahmematrix.
Selbstprüfung
Warum reicht Annotationstausch nicht?
Weil Verträge, Transaktionen, Security, Daten und Betriebsverhalten ebenfalls betroffen sind.
Was ist ein guter erster Migrationsschnitt?
Klein, fachlich klar, messbar, reversibel und mit begrenzten Abhängigkeiten.
Wozu dienen Characterization Tests?
Sie sichern beobachtbares Legacy-Verhalten, bevor intern verändert wird.
Gesamtarchitektur, Entscheidungen und Abschlussreview
Alle fünf Perspektiven
- Tag 1 · Context und ContainerAkteure, Systeme, Anwendungen, Datenspeicher und Messaging konsolidieren.Nachweis: C4 Context + Container.
- Tag 2 · Components und SequenceEin Kernmodul und einen kritischen Ablauf detaillieren.Nachweis: Component + Sequence Diagram.
- Tag 3 · Deployment und Data OwnershipRuntime, Skalierung, Datenbesitz und Recovery verbinden.Nachweis: Deployment + Data Map.
- Tag 4 · Operations ViewSLOs, Telemetrie, Alerts und Runbooks an die Architektur hängen.Nachweis: Operations Architecture.
- Tag 5 · Architecture ReviewEntscheidungen, Risiken, Alternativen und nächste Schritte verteidigen.Nachweis: Review-Unterlagen und ADR-Index.
- Tag 6 · Teach-back und Prüfung45 Minuten Gesamtvortrag plus Fragen ohne Unterlagen.Nachweis: Selbstbewertung und 90-Tage-Folgeplan.
Selbstprüfung
Welche sieben Ansichten bilden das Abschlussbild?
Context, Container, Component, Sequence, Deployment, Data Ownership und Operations.
Wann ist Wissen wirklich integriert?
Wenn ein Detail fachlich, architektonisch, technisch, betrieblich und strategisch eingeordnet werden kann.
Was folgt nach dem Kernpfad?
Gezielte Vertiefung anhand der erkannten Lücken, nicht lineares Abarbeiten aller Sammlungen.