Entwurfsmuster im Beispielcode

Diese Übersicht vermerkt, welche Entwurfsmuster und Modernisierungsmuster im Beispielprojekt verwendet werden. Sie ist bewusst praxisnah: Es geht nicht nur um klassische GoF-Pattern, sondern auch um Enterprise-, DDD-, Test- und Migrationsmuster.

Kurzüberblick

Details

1. Ports & Adapters / Hexagonal Architecture

Kategorie: Architektur-/Integrationsmuster

Warum im Projekt: Fachliche Use Cases hängen nur von Ports ab; technische Details liegen in Infrastruktur-Adaptern.

Hinweis: Das ist das zentrale Modernisierungsmuster des Projekts.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/ClaimRepository.java
• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/PaymentReleasePort.java
• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/AuditLogPort.java
• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/payment/PaymentReleaseSoapAdapter.java
• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/audit/StructuredAuditLogAdapter.java

2. Repository

Kategorie: Persistenzmuster

Warum im Projekt: Der Use Case arbeitet gegen ein fachliches Repository-Interface statt direkt gegen JPA/JDBC/Stored Procedures.

Hinweis: Hilft, Legacy-DAO- und Stored-Procedure-Abhängigkeiten aus dem Application Layer herauszuhalten.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/ClaimRepository.java
• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/adapter/jpa/JpaClaimRepository.java
• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/adapter/jpa/InMemoryJpaClaimRepository.java

3. Adapter

Kategorie: Strukturmuster

Warum im Projekt: Externe Systeme werden an fachliche Ports angepasst.

Hinweis: Adapter kapseln SOAP, LDAP, Fileshare, Audit und andere Infrastrukturdetails.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/document/FileShareDocumentStorageAdapter.java
• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/fraud/FraudRiskSoapAdapter.java
• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/coverage/CoverageSoapAdapter.java
• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/security/LdapSecurityContextAdapter.java

4. Anti-Corruption Layer

Kategorie: Integrations-/DDD-Muster

Warum im Projekt: Legacy-Begriffe und Fremdsystemmodelle werden in interne fachliche Modelle übersetzt.

Hinweis: Wichtig für Strangler-Migration, weil Legacy-Schnittstellen nicht direkt in den neuen Kern eindringen.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/fraud/FraudRiskSoapAntiCorruptionAdapter.java
• 03_after_refactoring_modular/claim-soap-api/src/main/java/com/seb4u/demo/claims/soap/ClaimSoapCompatibilityMapper.java

5. Command Object

Kategorie: Use-Case-/Application-Muster

Warum im Projekt: Alle Eingaben eines Use Cases werden in einem expliziten Command gebündelt.

Hinweis: Ersetzt lange Parameterlisten und unklare Übergabeobjekte aus dem Legacy-Code.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/command/ProcessClaimDecisionCommand.java
• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/command/SubmitClaimDocumentCommand.java
• 02_refactoring_steps/03_command_extraction/ProcessClaimDecisionCommand.java

6. Command Handler / Use Case Interactor

Kategorie: Application-Service-Muster

Warum im Projekt: Ein Handler orchestriert genau einen fachlichen Anwendungsfall.

Hinweis: Der Handler ersetzt Teile der Monster Method durch nachvollziehbare Use-Case-Schritte.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/handler/ProcessClaimDecisionHandler.java
• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/handler/SubmitClaimDocumentHandler.java
• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/handler/PrepareClaimPaymentHandler.java

7. Policy / Domain Service

Kategorie: Fachlogikmuster

Warum im Projekt: Regeln, die nicht sauber in eine einzelne Entity passen, werden als Policy modelliert.

Hinweis: Gut geeignet für Statusübergänge, Betragsregeln und Autorisierung.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-domain/src/main/java/com/seb4u/demo/claims/domain/ClaimTransitionPolicy.java
• 03_after_refactoring_modular/claim-domain/src/main/java/com/seb4u/demo/claims/domain/service/ClaimAmountPolicy.java
• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/policy/AuthorizationPolicy.java

8. Specification

Kategorie: Fachlogikmuster

Warum im Projekt: Eine fachliche Bedingung wird als wiederverwendbares Objekt formuliert.

Hinweis: Macht komplexe if-Bedingungen lesbarer und testbarer.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-domain/src/main/java/com/seb4u/demo/claims/domain/policy/CoverageSpecification.java

9. State Transition / State-Machine light

Kategorie: Verhaltensmuster

Warum im Projekt: Erlaubte Statuswechsel werden zentral modelliert und validiert.

Hinweis: Es ist bewusst keine schwere State-Machine-Library, sondern eine einfache fachliche Übergangsregel.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-domain/src/main/java/com/seb4u/demo/claims/domain/ClaimStatus.java
• 03_after_refactoring_modular/claim-domain/src/main/java/com/seb4u/demo/claims/domain/ClaimTransitionPolicy.java
• 03_after_refactoring_modular/claim-domain/src/test/java/com/seb4u/demo/claims/domain/ClaimTransitionPolicyTest.java

10. Workflow Orchestrator

Kategorie: Application-/Prozessmuster

Warum im Projekt: Mehrere Use-Case-Schritte und technische Folgeaktionen werden in einem Prozessfluss koordiniert.

Hinweis: Trennt Use-Case-Logik vom Prozessfluss und von Event-/Outbox-Aktionen.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-workflow/src/main/java/com/seb4u/demo/claims/workflow/ClaimDecisionWorkflowOrchestrator.java

11. Outbox Pattern

Kategorie: Integrations-/Resilienz-Muster

Warum im Projekt: Ereignisse werden zuverlässig gespeichert, bevor sie asynchron veröffentlicht werden.

Hinweis: Ersetzt direkte JMS-Publizierung im Legacy-Code und reduziert Konsistenzrisiken.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/OutboxPort.java
• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/outbox/JdbcOutboxAdapter.java
• 03_after_refactoring_modular/claim-workflow/src/main/java/com/seb4u/demo/claims/workflow/ClaimDecisionWorkflowOrchestrator.java

12. Idempotency Pattern

Kategorie: Resilienz-/Integrationsmuster

Warum im Projekt: Wiederholte technische Aufrufe werden sicher gemacht, damit z. B. Zahlungen nicht doppelt vorbereitet werden.

Hinweis: Besonders wichtig bei Payment, Retry, MQ und OpenShift-Restarts.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/port/IdempotencyPort.java
• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/idempotency/InMemoryIdempotencyAdapter.java
• 03_after_refactoring_modular/claim-application/src/test/java/com/seb4u/demo/claims/application/InMemoryIdempotencyPort.java

13. Mapper / Translator

Kategorie: Integrationsmuster

Warum im Projekt: Legacy- oder API-Formate werden in interne Begriffe übersetzt.

Hinweis: Schützt die Fachlogik vor Transport- und Legacy-Schnittstellendetails.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-soap-api/src/main/java/com/seb4u/demo/claims/soap/ClaimSoapCompatibilityMapper.java
• 03_after_refactoring_modular/claim-rest-api/src/main/java/com/seb4u/demo/claims/rest/ClaimDecisionRequest.java
• 03_after_refactoring_modular/claim-rest-api/src/main/java/com/seb4u/demo/claims/rest/ClaimDecisionResponse.java

14. DTO

Kategorie: API-/Transportmuster

Warum im Projekt: Transportdaten werden von Domain-Objekten getrennt.

Hinweis: Verhindert, dass REST/SOAP-Modelle direkt zur Domain werden.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-rest-api/src/main/java/com/seb4u/demo/claims/rest/ClaimDecisionRequest.java
• 03_after_refactoring_modular/claim-rest-api/src/main/java/com/seb4u/demo/claims/rest/ClaimDecisionResponse.java
• 03_after_refactoring_modular/claim-application/src/main/java/com/seb4u/demo/claims/application/command/ProcessClaimDecisionResult.java

15. Registry / Composition Root light

Kategorie: Verdrahtungsmuster

Warum im Projekt: Adapter-Zuordnungen werden nachvollziehbar dokumentiert bzw. zentral gesammelt.

Hinweis: Didaktische Alternative zu echter Spring/CDI-Konfiguration im Beispielprojekt.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-infrastructure/src/main/java/com/seb4u/demo/claims/infrastructure/config/AdapterRegistryV9.java

16. Test Data Builder

Kategorie: Testmuster

Warum im Projekt: Testdaten werden lesbar und variierbar aufgebaut.

Hinweis: Reduziert Setup-Rauschen in Tests.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-application/src/test/java/com/seb4u/demo/claims/application/builder/ClaimTestDataBuilder.java

17. Object Mother

Kategorie: Testmuster

Warum im Projekt: Häufig verwendete Standard-Testobjekte werden über sprechende Methoden bereitgestellt.

Hinweis: Gut für wenige Standard-Szenarien, aber nicht für jede Variation.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-application/src/test/java/com/seb4u/demo/claims/application/fixture/ClaimObjectMother.java

18. Fake / Spy Test Double

Kategorie: Testmuster

Warum im Projekt: Ports werden im Test durch kontrollierbare Ersatzimplementierungen ersetzt.

Hinweis: Passt direkt zur Ports-and-Adapters-Architektur.

Vorkommen im Code:

• 03_after_refactoring_modular/claim-application/src/test/java/com/seb4u/demo/claims/application/fake/InMemoryClaimRepository.java
• 03_after_refactoring_modular/claim-application/src/test/java/com/seb4u/demo/claims/application/fake/FakeAuditLogPort.java
• 03_after_refactoring_modular/claim-application/src/test/java/com/seb4u/demo/claims/application/fake/SpyPaymentReleasePort.java
• 03_after_refactoring_modular/claim-application/src/test/java/com/seb4u/demo/claims/application/SpyAuditLogPort.java

19. Strangler Fig Pattern

Kategorie: Modernisierungsmuster

Warum im Projekt: Legacy-Funktionen werden schrittweise durch neue Module ersetzt, ohne Big-Bang-Migration.

Hinweis: Das zentrale Migrationsprinzip des Projekts.

Vorkommen im Code:

• 03_after_refactoring_modular/migration-tests/src/test/java/com/seb4u/demo/claims/migration/LegacyVsModularDecisionComparisonTest.java
• 03_after_refactoring_modular/migration-tests/src/test/java/com/seb4u/demo/claims/migration/SoapCompatibilityMigrationIT.java
• cutover-plan *(Pfad prüfen / konzeptionelle Referenz)*

20. Golden Master / Characterization Test

Kategorie: Refactoring-Sicherheitsmuster

Warum im Projekt: Legacy-Verhalten wird vor dem Refactoring eingefroren und später mit der neuen Implementierung verglichen.

Hinweis: Kein GoF-Entwurfsmuster, aber ein zentrales Refactoring-Muster.

Vorkommen im Code:

• 02_refactoring_steps/02_golden_master/GoldenMasterSnapshot.java
• 02_refactoring_steps/02_golden_master/LegacyProcessClaimDecisionCharacterizationTest.java
• 03_after_refactoring_modular/migration-tests/src/test/java/com/seb4u/demo/claims/migration/LegacyVsModularDecisionComparisonTest.java

Abgrenzung: Muster vs. Anti-Pattern

• Die Legacy-LegacyClaimFacadeBean.processClaimDecision(...) ist bewusst als Monster Method / God Service dargestellt. Das ist kein Zielmuster, sondern der Ausgangspunkt des Refactorings.
• Die moderne Zielstruktur verwendet dagegen kleinere Use Cases, Ports, Policies, Adapter und Tests als fachlich nachvollziehbare Bausteine.

Lesepfad

1. Zuerst Command Object, Command Handler und Policy lesen.
2. Danach Ports & Adapters, Repository, Adapter und Anti-Corruption Layer betrachten.
3. Anschließend Outbox, Idempotency und Strangler Fig als Migrations- und Betriebsaspekte nachvollziehen.
4. Zum Schluss die Testmuster Test Data Builder, Object Mother, Fake/Spy und Golden Master vergleichen.