Projekt-Walkthrough

Dieses Dokument verbindet das Handbuch mit dem Beispielprojekt. Die Reihenfolge ist bewusst praktisch: zuerst lesen, dann konkrete Dateien ansehen, danach eine kleine Aufgabe lösen.

1. Einstieg: Was wird modernisiert?

Ziel: Verstehen, warum dieses Projekt nicht als Big-Bang-Rewrite behandelt wird.

Lesen:

• lernbuch/markdown/legacy-claims-handbuch.html, Kapitel 2 und 3

Ansehen im Projekt:

• beispielprojekt/00_project_navigation/lernweg.html

• beispielprojekt/00_project_navigation/PROJECT_MAP.html

• beispielprojekt/01_before_refactoring_legacy/README.html

Prüffrage:

Welche drei Abhängigkeiten machen das Legacy-System schwer testbar?

Erwartung:

• EJB/WebSphere-Runtime

• Datenbank/Stored Procedures

• SOAP/JMS/LDAP/FileShare-Zugriffe direkt in Fachabläufen

2. Legacy-Kern finden

Ziel: Die zentrale problematische Stelle identifizieren.

Ansehen:

• beispielprojekt/01_before_refactoring_legacy/legacy-websphere-ear/src/main/java/com/seb4u/demo/claims/legacy/ejb/LegacyClaimFacadeBean.java

• beispielprojekt/01_before_refactoring_legacy/legacy-websphere-ear/src/main/java/com/seb4u/demo/claims/legacy/dao/LegacyClaimDao.java

• beispielprojekt/01_before_refactoring_legacy/legacy-websphere-ear/src/main/java/com/seb4u/demo/claims/legacy/security/JaasRoleChecker.java

Notiere:

• Welche fachlichen Entscheidungen werden direkt im EJB getroffen?

• Welche externen Systeme werden direkt oder indirekt aufgerufen?

• Welche Seiteneffekte entstehen?

3. Sicherheitsnetz aufbauen

Ziel: Refactoring erst beginnen, wenn Verhalten sichtbar und vergleichbar ist.

Ansehen:

• beispielprojekt/02_refactoring_steps/01_inventory_characterization/InventoryReport.html

• beispielprojekt/02_refactoring_steps/02_golden_master/GoldenMasterSnapshot.java

• beispielprojekt/02_refactoring_steps/02_golden_master/LegacyProcessClaimDecisionCharacterizationTest.java

Merksatz:

Characterization Tests beschreiben zuerst vorhandenes Verhalten. Sie beweisen noch nicht, dass das Verhalten fachlich schön ist.

4. Command und Ergebnisobjekt verstehen

Ziel: Primitive Parameterlisten und unklare Rückgaben ersetzen.

Ansehen:

• beispielprojekt/02_refactoring_steps/03_command_extraction/ProcessClaimDecisionCommand.java

• beispielprojekt/03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/command/ProcessClaimDecisionCommand.java

• beispielprojekt/03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/command/ProcessClaimDecisionResult.java

Aufgabe:

Erkläre, warum ein Command Object später Tests, Logging und API-Mapping einfacher macht.

5. Fachmodell und Policy

Ziel: Statusübergänge aus if/else-Blöcken herauslösen.

Ansehen:

• beispielprojekt/02_refactoring_steps/04_status_policy/ClaimTransitionPolicy.java

• beispielprojekt/03_after_refactoring_modular/claim-domain/src/main/java/com/seb4u/demo/claims/domain/ClaimTransitionPolicy.java

• beispielprojekt/03_after_refactoring_modular/claim-domain/src/test/java/com/seb4u/demo/claims/domain/ClaimTransitionPolicyTest.java

Erwartung:

• Fachregeln sollen im Domain-Modul liegen.

• Application Services orchestrieren, aber entscheiden nicht selbst jeden Statusübergang.

6. Ports & Adapter

Ziel: Externe Systeme austauschbar machen.

Ansehen:

• beispielprojekt/02_refactoring_steps/05_ports_extraction/PortsOverview.html

• beispielprojekt/03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/DocumentVerificationPort.java

• beispielprojekt/03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/FraudRiskPort.java

• beispielprojekt/03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/document/DocumentVerificationSoapAdapter.java

• beispielprojekt/03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/fraud/FraudRiskSoapAdapter.java

Merksatz:

Application kennt Ports. Infrastructure kennt technische Adapter. Domain kennt beides nicht.

7. Application Handler und Workflow

Ziel: Den neuen Use Case als klare Grenze verstehen.

Ansehen:

• beispielprojekt/03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/handler/ProcessClaimDecisionHandler.java

• beispielprojekt/03_after_refactoring_modular/claim-workflow/src/main/java/com/seb4u/demo/claims/workflow/ClaimDecisionWorkflowOrchestrator.java

• beispielprojekt/02_refactoring_steps/06_workflow_orchestrator/ClaimDecisionWorkflowOrchestrator.java

Prüffrage:

Was gehört in den Handler, was in den Workflow, was in die Domain?

8. Outbox, Idempotenz und Payment

Ziel: Seiteneffekte kontrollieren.

Ansehen:

• beispielprojekt/02_refactoring_steps/07_outbox_idempotency/OutboxDesign.html

• beispielprojekt/03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/outbox/JdbcOutboxAdapter.java

• beispielprojekt/03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/idempotency/InMemoryIdempotencyAdapter.java

• beispielprojekt/03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/payment/PaymentReleaseSoapAdapter.java

9. API-Schichten

Ziel: REST und SOAP als dünne Boundary verstehen.

Ansehen:

• beispielprojekt/03_after_refactoring_modular/claim-rest-api/src/main/java/com/seb4u/demo/claims/rest/ClaimDecisionRestController.java

• beispielprojekt/03_after_refactoring_modular/claim-soap-api/src/main/java/com/seb4u/demo/claims/soap/ClaimDecisionSoapEndpoint.java

• beispielprojekt/03_after_refactoring_modular/claim-openapi/src/main/openapi/claims-api.yaml

Erwartung:

• API-Schichten übersetzen Requests und Responses.

• Fachlogik bleibt im Application/Domain-Bereich.

10. OpenShift-Migration

Ziel: Verstehen, was aus WebSphere-Konfiguration, JNDI, Timer und Deployments wird.

Ansehen:

• beispielprojekt/04_migration_to_openshift/openshift/

• beispielprojekt/04_migration_to_openshift/runbooks/

• beispielprojekt/04_migration_to_openshift/database/

Prüffrage:

Welche Legacy-Runtime-Aspekte müssen bei OpenShift explizit modelliert werden?

Antwort:

• Konfiguration

• Secrets

• Health Checks

• Routes/Services

• CronJobs

• Ressourcenlimits

• Network Policies

• Observability

11. Finaler Lernpfad

Arbeite danach im Workbook weiter:

• workbook/markdown/refactoring-labs.html

• workbook/markdown/openshift-labs.html

• workbook/solutions/musterloesungen.html

• workbook/interview/senior-java-enterprise-fragen.html

Refactoring-Labs

Diese Labs sind praxisorientiert. Sie sind so formuliert, dass du sie direkt mit dem Beispielprojekt bearbeiten kannst.

Lab 1: Legacy-Verantwortungen sichtbar machen

Ziel: Die Monster Method fachlich zerlegen, ohne sofort Code zu verändern.

Dateien:

• beispielprojekt/01_before_refactoring_legacy/legacy-websphere-ear/src/main/java/com/seb4u/demo/claims/legacy/ejb/LegacyClaimFacadeBean.java

• beispielprojekt/01_before_refactoring_legacy/legacy-websphere-ear/src/main/java/com/seb4u/demo/claims/legacy/integration/FraudRiskSoapClient.java

• beispielprojekt/01_before_refactoring_legacy/legacy-websphere-ear/src/main/java/com/seb4u/demo/claims/legacy/integration/PaymentReleaseSoapClient.java

Aufgabe:

1. Lies die Legacy-Facade.

2. Markiere fachliche Entscheidungen, technische Zugriffe und Seiteneffekte.

3. Erstelle eine Tabelle mit den Spalten: Verantwortung, Legacy-Stelle, Ziel-Baustein, Risiko.

Ergebnis:

• Eine Verantwortungskarte für spätere Refactoring-Schritte.

Lab 2: Characterization Test entwerfen

Ziel: Vorhandenes Verhalten dokumentieren.

Dateien:

• beispielprojekt/02_refactoring_steps/02_golden_master/LegacyProcessClaimDecisionCharacterizationTest.java

• beispielprojekt/02_refactoring_steps/02_golden_master/GoldenMasterSnapshot.java

Aufgabe:

1. Definiere drei typische Claim-Szenarien.

2. Beschreibe je Szenario erwartete Legacy-Ausgabe.

3. Notiere alle Seiteneffekte, die nicht direkt im Return-Wert sichtbar sind.

Beispielszenarien:

• Claim mit vollständigen Dokumenten und niedrigem Fraud-Risk.

• Claim mit fehlenden Dokumenten.

• Claim mit hohem Fraud-Risk und Payment-Blockade.

Lab 3: Command Object bewerten

Ziel: Verstehen, warum Parameterlisten schlecht wartbar sind.

Dateien:

• beispielprojekt/02_refactoring_steps/03_command_extraction/ProcessClaimDecisionCommand.java

• beispielprojekt/03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/command/ProcessClaimDecisionCommand.java

Aufgabe:

1. Liste alle Eingabewerte des Use Cases.

2. Ordne sie fachlich: Claim, Benutzer, Entscheidung, Kommentar, Kontext.

3. Erkläre, welche Werte validiert werden sollten.

Lab 4: Policy statt if/else

Ziel: Statuslogik ins Domain-Modell verschieben.

Dateien:

• beispielprojekt/03_after_refactoring_modular/claim-domain/src/main/java/com/seb4u/demo/claims/domain/ClaimTransitionPolicy.java

• beispielprojekt/03_after_refactoring_modular/claim-domain/src/test/java/com/seb4u/demo/claims/domain/ClaimTransitionPolicyTest.java

Aufgabe:

1. Ergänze gedanklich eine Regel: Ein bereits geschlossener Claim darf nicht erneut freigegeben werden.

2. Beschreibe den Testfall.

3. Begründe, warum die Regel nicht im REST Controller liegen soll.

Lab 5: Port extrahieren

Ziel: Technischen SOAP-Zugriff durch Port entkoppeln.

Dateien:

• beispielprojekt/03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/DocumentVerificationPort.java

• beispielprojekt/03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/document/DocumentVerificationSoapAdapter.java

Aufgabe:

1. Beschreibe die fachliche Port-Signatur ohne SOAP-Begriffe.

2. Erkläre, welche Fehler der Adapter übersetzen muss.

3. Erstelle eine Liste möglicher Fake-Implementierungen für Tests.

Lab 6: Handler mit Fake Ports testen

Ziel: Application Handler ohne echte Infrastruktur testen.

Dateien:

• beispielprojekt/03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/handler/ProcessClaimDecisionHandler.java

• beispielprojekt/02_refactoring_steps/12_fake_ports_spies/README.html

Aufgabe:

1. Definiere Fake Ports für Repository, Fraud, Coverage, Payment, Audit.

2. Baue einen Testfall für erfolgreiche Freigabe.

3. Prüfe, dass Audit und Payment nur dann ausgelöst werden, wenn Fachregeln erfüllt sind.

Lab 7: Outbox statt direkter Publizierung

Ziel: Transaktionsgrenze von Messaging entkoppeln.

Dateien:

• beispielprojekt/02_refactoring_steps/07_outbox_idempotency/OutboxDesign.html

• beispielprojekt/03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/outbox/JdbcOutboxAdapter.java

Aufgabe:

1. Erkläre, warum direkte JMS-Publizierung in der Legacy-Methode riskant ist.

2. Definiere ein Outbox-Event für ClaimDecisionAccepted.

3. Beschreibe Retry- und Duplicate-Handling.

Lab 8: Read Model für Suche

Ziel: Query-/Reporting-Anforderungen getrennt vom Write-Modell betrachten.

Dateien:

• beispielprojekt/03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/ClaimSearchPort.java

• beispielprojekt/03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/adapter/jpa/JpaClaimRepository.java

Aufgabe:

1. Definiere drei Suchfilter für Claims.

2. Entscheide, welche Filter in ein Read Model gehören.

3. Erkläre, warum Reporting nicht direkt das Aggregate missbrauchen sollte.

Lab 9: Strangler für UI

Ziel: Partner Portal und Backoffice schrittweise entkoppeln.

Dateien:

• beispielprojekt/02_refactoring_steps/09_portal_backoffice_strangler/StranglerPlan.html

• beispielprojekt/01_before_refactoring_legacy/legacy-claims-partner-portal/src/main/java/com/seb4u/demo/claims/legacy/portal/LegacyPartnerPortalServlet.java

• beispielprojekt/01_before_refactoring_legacy/legacy-internal-claims-backoffice/src/main/java/com/seb4u/demo/claims/legacy/backoffice/InternalClaimsBackofficeBean.java

Aufgabe:

1. Wähle eine UI-Funktion für die erste Entkopplung.

2. Definiere eine moderne API-Grenze.

3. Beschreibe einen Rollback-Pfad.

Lab 10: Architekturtest entwerfen

Ziel: Modulregeln automatisiert absichern.

Dateien:

• beispielprojekt/03_after_refactoring_modular/claim-application/README.html

• beispielprojekt/03_after_refactoring_modular/claim-domain/README.html

• beispielprojekt/03_after_refactoring_modular/claim-infrastructure/README.html

Aufgabe:

1. Formuliere drei Architekturregeln.

2. Beispiel: Domain darf Infrastructure nicht importieren.

3. Beschreibe, wie ein ArchUnit-Test diese Regel prüfen würde.

OpenShift-Labs

Diese Labs verbinden Migration, Betrieb und Architekturentscheidungen.

Lab 1: WebSphere-Konfiguration nach OpenShift übertragen

Dateien:

• beispielprojekt/01_before_refactoring_legacy/legacy-websphere-ear/src/main/application/META-INF/application.xml

• beispielprojekt/01_before_refactoring_legacy/legacy-websphere-ear/src/main/application/META-INF/ibm-application-bnd.xml

• beispielprojekt/04_migration_to_openshift/openshift/

Aufgabe:

1. Liste alle Runtime-Aspekte aus WebSphere.

2. Ordne sie OpenShift-Objekten zu: ConfigMap, Secret, Deployment, Service, Route, CronJob.

3. Markiere, was nicht 1:1 migriert werden darf.

Lab 2: ConfigMap und Secret schneiden

Aufgabe:

1. Entscheide, welche Werte in ConfigMaps gehören.

2. Entscheide, welche Werte Secrets sein müssen.

3. Begründe, warum Passwörter nicht im Containerfile stehen dürfen.

Lab 3: Health Checks definieren

Aufgabe:

1. Definiere Readiness-Kriterien.

2. Definiere Liveness-Kriterien.

3. Erkläre, warum Datenbankausfall nicht immer Liveness-Failure sein sollte.

Lab 4: EJB Timer zu CronJob

Dateien:

• beispielprojekt/02_refactoring_steps/08_batch_sla/EscalationBatchPlan.html

• beispielprojekt/04_migration_to_openshift/openshift/

Aufgabe:

1. Beschreibe den Legacy-Timer.

2. Entwirf einen OpenShift CronJob.

3. Ergänze ein Locking-Konzept gegen doppelte Ausführung.

Lab 5: NetworkPolicy planen

Aufgabe:

1. Welche Pods dürfen zur Datenbank?

2. Welche Pods dürfen externe SOAP-Systeme erreichen?

3. Welche Inbound-Verbindungen sind erlaubt?

Lab 6: Rollback-Plan schreiben

Aufgabe:

1. Definiere technische Rollback-Auslöser.

2. Definiere fachliche Rollback-Auslöser.

3. Beschreibe, welche Daten nach einem Rollback geprüft werden müssen.

Lab 7: Observability prüfen

Dateien:

• beispielprojekt/02_refactoring_steps/20_observability_v8/README.html

• beispielprojekt/04_migration_to_openshift/runbooks/

Aufgabe:

1. Definiere fünf wichtige Logs.

2. Definiere fünf wichtige Metriken.

3. Definiere drei Trace-Spans für den Claim-Decision-Prozess.

Lab 8: Smoke-Test Checkliste

Aufgabe:

1. Schreibe eine Checkliste für Deployment Smoke Tests.

2. Prüfe Route, Health, API, DB, Security, Outbox.

3. Definiere ein klares Go/No-Go-Ergebnis.

Musterlösungen

Diese Musterlösungen sind bewusst kompakt. Sie zeigen die Denkweise, nicht nur eine richtige Zeile Code.

Lösung zu Refactoring Lab 1

Eine sinnvolle Verantwortungskarte:

Lösung zu Refactoring Lab 2

Ein guter Characterization Test prüft nicht nur den Return-Wert, sondern auch sichtbare Seiteneffekte:

• neuer Claim-Status

• Audit-Eintrag

• Payment-Request

• Notification-Event

• Search-Index-Aktualisierung

• Fehlercode bei externem Systemausfall

Wichtig: Der Test darf anfangs unschön sein, solange er vorhandenes Verhalten zuverlässig dokumentiert.

Lösung zu Refactoring Lab 3

Ein Command Object ist besser, weil:

• alle Eingaben versionierbar werden,

• Validierung zentralisiert wird,

• Logging/Audit einfacher wird,

• REST/SOAP Mapping klarer wird,

• Tests lesbarer werden,

• neue Felder ergänzt werden können, ohne Methodensignaturen überall zu ändern.

Lösung zu Refactoring Lab 4

Die Regel „geschlossener Claim darf nicht erneut freigegeben werden“ gehört in die Domain-Policy, weil sie unabhängig von REST, SOAP oder Batch gilt. Ein Controller darf höchstens Eingaben übersetzen, aber nicht fachliche Statusregeln besitzen.

Lösung zu Refactoring Lab 5

Eine gute Port-Signatur verwendet Fachbegriffe:

DocumentVerificationResult verifyDocuments(ClaimId claimId, CustomerId customerId);

Nicht gut:

SoapDocumentResponse callDocumentService(String xmlPayload);

Der Adapter übersetzt SOAP, technische Fehler, Timeouts und fremde Codes in fachlich verständliche Ergebnisse.

Lösung zu Refactoring Lab 6

Fake Ports sollten gezielt Verhalten simulieren:

• RepositoryFake speichert Claims im Speicher.

• FraudRiskFake liefert LOW, MEDIUM oder HIGH.

• CoverageFake liefert covered/not covered.

• PaymentSpy merkt, ob eine Zahlung ausgelöst wurde.

• AuditSpy merkt, welche Events geschrieben wurden.

So wird geprüft, ob der Handler richtig orchestriert, ohne echte Infrastruktur zu starten.

Lösung zu Refactoring Lab 7

Direkte JMS-Publizierung ist riskant, weil Datenbanktransaktion und Messaging-Transaktion auseinanderlaufen können. Outbox schreibt das Event zuerst innerhalb der DB-Transaktion. Ein separater Publisher versendet später zuverlässig und idempotent.

Lösung zu OpenShift Lab 1

Typische Zuordnung:

Lösung zu OpenShift Lab 3

Readiness heißt: Der Pod kann Traffic annehmen. Liveness heißt: Der Prozess ist in einem Zustand, aus dem er nicht mehr selbst herauskommt. Eine kurz ausgefallene Datenbank sollte oft Readiness beeinflussen, aber nicht sofort Liveness, sonst entstehen Restart-Schleifen.

Lösung zu OpenShift Lab 6

Ein Rollback-Plan braucht:

• klare Auslöser,

• letzte bekannte gute Version,

• Datenprüfung,

• Kommunikationsplan,

• Entscheidung, ob Events replayed oder kompensiert werden,

• Nachprüfung von Audit, Payment und Notification.

Senior-Java-/Enterprise-Interviewfragen zum Projekt

1. Warum keine Big-Bang-Migration?

Antwort: Weil Legacy-Systeme oft versteckte fachliche Regeln, Seiteneffekte und externe Abhängigkeiten enthalten. Ein Big Bang erhöht Risiko, erschwert Rollback und macht Fehlerursachen unklar.

2. Was ist der Unterschied zwischen Characterization Test und Unit Test?

Antwort: Characterization Tests dokumentieren vorhandenes Verhalten, auch wenn es unschön ist. Unit Tests prüfen gezielt eine kleine, sauber geschnittene Einheit gegen erwartetes Verhalten.

3. Warum Ports & Adapters?

Antwort: Application und Domain werden von technischen Details entkoppelt. Dadurch können SOAP, JMS, Datenbank, LDAP oder FileShare ersetzt oder gefaked werden.

4. Warum Outbox Pattern?

Antwort: Weil DB-Änderung und Event-Versand zuverlässig gekoppelt werden müssen. Das Event wird in derselben Transaktion gespeichert und später kontrolliert publiziert.

5. Warum Domain frei von Infrastruktur halten?

Antwort: Fachlogik bleibt testbar, portabel und unabhängig von Frameworks. Änderungen an Datenbank, API oder Runtime berühren nicht jede Fachregel.

6. Was gehört in den Application Service?

Antwort: Orchestrierung eines Use Cases, Laden/Speichern über Ports, Aufruf von Policies, Koordination von Seiteneffekten. Nicht: technische SOAP-Details oder UI-Logik.

7. Wie migriert man EJB Timer nach OpenShift?

Antwort: Über CronJobs oder externe Scheduler. Zusätzlich braucht man Locking/Idempotenz, weil Pods mehrfach laufen können.

8. Warum ist Role Mapping bei Migration gefährlich?

Antwort: Weil alte JAAS-/LDAP-Rollen oft implizit und technisch gewachsen sind. Falsches Mapping kann unberechtigte Freigaben oder blockierte Fachprozesse verursachen.

9. Warum REST nicht automatisch besser als SOAP ist?

Antwort: REST ist nur eine Schnittstellenform. Ohne saubere Fachgrenzen kann auch REST nur eine neue Hülle um alte Kopplung sein.

10. Was ist ein guter Migrations-Smoke-Test?

Antwort: Er prüft nicht nur HTTP 200, sondern Route, Health, Auth, Datenbank, Fachfall, Audit, Outbox und Rollback-relevante Seiteneffekte.

11. Wie erkennt man zu viele Module?

Antwort: Wenn Module keine eigenständige fachliche Verantwortung haben, nur eine Klasse enthalten oder ständig zyklisch gemeinsam geändert werden.

12. Warum Mapping-Tests wichtig sind?

Antwort: Sie beweisen, dass neue Use Cases fachlich dieselben Ergebnisse liefern wie Legacy-Pfade, bevor Traffic umgeschaltet wird.

Lern- und Qualitätscheckliste

Tagesplan für 7 Tage

Tag 1: Orientierung

• Handbuch Kapitel 1–2 lesen

• lernweg.html und PROJECT_MAP.html ansehen

• Systemlandschaft skizzieren

Tag 2: Legacy verstehen

• Kapitel 3 lesen

• Monster Method analysieren

• Verantwortungskarte ausfüllen

Tag 3: Sicherheitsnetz

• Characterization und Golden Master verstehen

• Refactoring Labs 1–3 bearbeiten

Tag 4: Domain und Ports

• Policy, Command, Ports analysieren

• Refactoring Labs 4–6 bearbeiten

Tag 5: Workflow und Seiteneffekte

• Handler, Workflow, Outbox, Payment ansehen

• Refactoring Labs 7–8 bearbeiten

Tag 6: OpenShift

• Kapitel 6 lesen

• OpenShift Labs 1–5 bearbeiten

Tag 7: Abschluss

• Cutover und Rollback erklären

• Interviewfragen beantworten

• eigene Architekturentscheidungen formulieren

Abschlusskriterien

Du hast das Projekt verstanden, wenn du erklären kannst:

• warum Legacy nicht sofort ersetzt wird,

• wie die Monster Method zerlegt wird,

• welche Ports gebraucht werden,

• warum Outbox und Idempotenz wichtig sind,

• wie OpenShift alte Runtime-Aufgaben übernimmt,

• welche Tests vor Cutover nötig sind.

Architecture Decision Records