Musterlösungen
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:
| Verantwortung | Legacy-Stelle | Ziel-Baustein | Risiko |
|---|---|---|---|
| Benutzerrolle prüfen | JaasRoleChecker / EJB Context | AuthorizationPolicy + SecurityContextPort | falsches Role Mapping |
| Claim laden | LegacyClaimDao | ClaimRepository | Stored-Procedure-Seiteneffekte |
| Dokumente prüfen | SOAP/DMS Adapter | DocumentVerificationPort | Timeouts, alte Fehlercodes |
| Fraud bewerten | FraudRiskSoapClient | FraudRiskPort | inkonsistente Risk Scores |
| Zahlung freigeben | PaymentReleaseSoapClient | PaymentReleasePort + Idempotenz | doppelte Zahlung |
| Audit schreiben | Stored Procedure / Logger | AuditLogPort | Compliance-Lücke |
| Benachrichtigung senden | JMS/Mail | Outbox + Notification Adapter | doppelte oder fehlende Nachricht |
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:
| WebSphere-Aspekt | OpenShift-Ziel |
|---|---|
| JNDI DataSource | Secret + ConfigMap + Deployment Env |
| EJB Timer | CronJob |
| EAR Deployment | Container Image + Deployment |
| JAAS Rollen | Security Adapter + Role Mapping |
| Server Bindings | Service/Route/NetworkPolicy |
| JVM Parameter | Deployment Ressourcen + Env |
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.