Master 24
Design Patterns und Legacy-Antipatterns
Pattern, Zweck, Einsatzort und Begründung – direkt auf den realen Quellcode bezogen.
Verwendete Muster
| Pattern | Zweck | Einsatzort | Begründung |
|---|---|---|---|
| Transaction Script / God Class (Legacy-Antipattern) | Bewusst historisch gewachsene Ablaufsteuerung in wenigen EJB-Klassen sichtbar machen. |
enterprise-legacy-monolith/.../ejb/*MonsterBean.java
|
Zeigt lange Transaktionen, gemischte Verantwortlichkeiten und hohe Änderungskosten als Refactoring-Ausgangspunkt. |
| Facade | Legacy-Zugriff hinter einer stabilen Schnittstelle bündeln. |
enterprise-legacy-monolith/.../LegacyOrderFacade.java
|
Verhindert, dass Migrationsteile direkt an interne EJB-Details gekoppelt werden. |
| Template Method | Gemeinsame Ablaufstruktur mit austauschbaren Schritten kapseln. |
solid-refactoring/...
|
Macht Transaktions- und Fehlerabläufe nachvollziehbar, ohne fachliche Schritte zu duplizieren. |
| Gateway | Datenbank- und Fremdsystemzugriffe hinter fachnahen Ports kapseln. |
LegacyMixedPersistenceGateway und Integrationsadapter
|
Erlaubt JPA, JDBC, Stored Procedures und Remote-Techniken kontrolliert auszutauschen. |
| Service Locator | Remote-EJB per JNDI auflösen. |
ContractRemoteEjbClient
|
Dokumentiert ein typisches Legacy-Integrationsmuster; Offline-Fallback ist explizit getrennt. |
| Adapter | SOAP-, REST-, EJB- und JMS-Technik in einheitliche Anwendungsschnittstellen übersetzen. |
PaymentProviderSoapClient, CarrierRateRestClient, ContractRemoteEjbClient, LegacyJmsRequestReply
|
Transportdetails und technische Fehler bleiben außerhalb der Fachlogik. |
| Request–Reply + Correlation ID | JMS-Anfrage und Antwort eindeutig zusammenführen. |
LegacyJmsRequestReply
|
Verhindert Antwortverwechslungen bei parallelen Nachrichten. |
| Anti-Corruption Layer | Legacy-Status, DTOs und Fehler in ein modernes Domänenmodell übersetzen. |
anti-corruption-layer
|
Schützt das Zielmodell vor historischer Terminologie und technischen Sonderfällen. |
| Strangler Fig | Aufrufe schrittweise zwischen Legacy und Modern routen. |
strangler-router
|
Unterstützt kontrollierte Migration, Fallback und schrittweisen Rollout. |
| Domain Aggregate (Prozess-Zustand) | Zustand über mehrere Aufrufe hinweg konsistent halten und ungültige Übergänge verweigern. |
strangler-router/.../MigrationProgress.java, parallel-run-comparison/.../ComparisonRun.java
|
Ein abgeschlossener Migrations- bzw. Vergleichslauf darf sich nicht mehr durch nachträgliche Legacy-Treffer oder neue Batches verändern; das Aggregat setzt diese Regel technisch durch statt sie nur zu dokumentieren. |
| Repository | Persistenzzugriff im Spring-Boot-Zielsystem abstrahieren. |
spring-boot-migration/.../*Repository.java
|
Trennt Application Service und Datenzugriff. |
| Application Service | Use Case und Transaktionsgrenze koordinieren. |
solid-refactoring und spring-boot-migration
|
Hält Controller und Adapter frei von Orchestrierungslogik. |
| Transactional Outbox | Fachänderung und Event in einer Datenbanktransaktion speichern. |
spring-boot-migration/.../outbox
|
Verhindert das klassische Dual-Write-Problem zwischen Datenbank und Kafka. |
| Lease / Competing Consumers | Outbox-Einträge zeitlich begrenzt durch einen Worker beanspruchen. |
OutboxClaimService und Flyway V2
|
Erlaubt parallele Worker und Recovery nach Prozessabbruch. |
| Idempotent Consumer / Inbox | Bereits verarbeitete Event-IDs eindeutig speichern. |
spring-boot-migration/.../inbox und Flyway V3
|
Beherrscht unvermeidbare Mehrfachzustellung bei At-least-once Messaging. |
| Golden Master / Characterization Test | Beobachtbares Legacy-Verhalten vor dem Refactoring festhalten. |
characterization-tests
|
Schützt wichtige Altverträge, ohne die interne Struktur zu idealisieren. |
Einordnung
Die Legacy-Antipatterns sind absichtlich sichtbar, werden aber nicht als Zielarchitektur empfohlen. Die moderne Seite verwendet Ports, Adapter, Application Services, Transactional Outbox und Inbox, um Verantwortlichkeiten und Fehlerszenarien explizit zu behandeln.