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
• README

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:

• OutboxDesign
• 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:

• StranglerPlan
• 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:

• README
• README
• README

Aufgabe:

1. Formuliere drei Architekturregeln.
2. Beispiel: Domain darf Infrastructure nicht importieren.
3. Beschreibe, wie ein ArchUnit-Test diese Regel prüfen würde.