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:

legacy-claims-handbuch, Kapitel 2 und 3

Ansehen im Projekt:

PROJECT_MAP
README

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:

InventoryReport
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:

PortsOverview
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:

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