SOLID-Refactoring vom God Object
Das Refactoring folgt nicht dem Big-Bang-Prinzip. Zuerst wird Verhalten eingefroren, dann werden reine Fachkonzepte isoliert, anschließend Portgrenzen eingeführt und erst zuletzt der Runtime-Wechsel zu Spring Boot vollzogen.
Refactoring-Reihenfolge
Verhalten charakterisieren
Die drei zentralen Ergebniszustände werden als ausführbare Baseline festgehalten. Änderungen dürfen die beobachtete Semantik nicht still verändern.
Value Objects extrahieren
ClaimId und Money ersetzen primitive Strings und lose BigDecimal-/Currency-Kombinationen.
Aggregate bilden
Der Statuswechsel wandert in Claim. Terminalzustände und Domain Events werden an einer Stelle kontrolliert.
Regeln als Policies
Regelblöcke werden über ClaimPolicy und CompositeClaimPolicy erweiterbar, unabhängig testbar und nach dem Open/Closed Principle strukturiert.
Focused Ports
Repository, Fraud, Coverage, Documents, Payment, Idempotency, Audit und Event Publishing erhalten kleine Interfaces statt eines generischen Gateway-Objekts.
Nebenwirkungen trennen
Persistenz und Outbox bleiben in einer lokalen Transaktion. Externe JMS-Zustellung läuft anschließend wiederholbar.
Traffic strangeln
Ein Legacy-kompatibler Bridge-Endpunkt leitet ausgewählte Operationen an den neuen Use Case. Weitere Domänenslices können schrittweise folgen.
Monster-Methode zu Verantwortlichkeiten
| Vorher | Nachher | SOLID-Effekt |
|---|---|---|
| String-/Map-basierter Request | ProcessClaimCommand, ClaimId, Money | SRP, Typensicherheit |
| 60 Claims-Regeln und weitere domänenspezifische Kontrollkaskaden | ClaimPolicy-Strategien | OCP, testbare Regeln |
| SQL in EJB | ClaimRepository | DIP, ISP |
| Generisches SOAP-Gateway | FraudAssessmentPort, CoveragePort, PaymentPort | ISP, Anti-Corruption Layer |
| JMS in Business-Transaktion | OutboxPort + OutboxPublisher | Transaktionssicherheit |
| Globale Containerabhängigkeit | Constructor Injection / Composition Root | DIP, testbarer Kern |
Konkrete Codepfade
Aggregate
Claim.java mit kontrollierten Statusübergängen.
Use Case
Kleine Orchestrierung statt einer 1.248-zeiligen Claims-Hauptmethode.
Policies
Strategy + Composite statt Inline-Regelblöcken.
Composition Root
Abhängigkeiten werden an einer Stelle aufgebaut.