Migrationsmuster¶
Die meiste JVM-Modernisierungsarbeit lässt sich auf drei strukturelle Probleme reduzieren: Legacy-Code läuft hinter HTTP, oder er wird direkt als Klasse aufgerufen, oder die Domänenmodelle stimmen nicht überein. Für jedes gibt es ein Muster — jeweils mit einem ausführbaren Spring-Boot-Beispiel, das die konkrete Code-Transformation zeigt.
Musterübersicht¶
| Muster | Situation | Risiko | Typische Dauer |
|---|---|---|---|
| Strangler Fig | Per HTTP erreichbares Legacy; Route-für-Route-Ablösung | Gering — Legacy bedient anfangs noch den gesamten Traffic | Wochen bis Monate pro Route |
| Branch-by-Abstraction | In-Process-Klassen-/Service-Ablösung | Mittel — beide Implementierungen müssen parallel gepflegt werden | Tage bis Wochen pro Komponente |
| Anti-Corruption Layer | Unterschiedliche Domänenmodelle zwischen Legacy und Neu | Gering — Übersetzung ist explizit und testbar | 1–3 Tage Aufbau; laufend bei Modelldivergenz |
Muster kombinieren¶
Diese Muster schließen sich nicht gegenseitig aus. Eine typische Modernisierung verwendet alle drei:
- Strangler Fig — leitet Traffic zu einem neuen Spring-Boot-Service um.
- Branch-by-Abstraction — ersetzt interne Services innerhalb dieses neuen Systems, während Legacy-Code schrittweise extrahiert wird.
- Anti-Corruption Layer — sitzt an der Grenze zwischen neuem und altem Service, um Domänenmodell-Pollution zu verhindern.
Die Reihenfolge ist wichtig: der Strangler Fig steuert, was das Legacy-System überhaupt noch erreicht. Branch-by-Abstraction restrukturiert die Interna des neuen Services. Der ACL verhindert, dass die beiden Domänenmodelle ineinander bluten.