Entwurfsmuster-Dokumentation
Alle im Maven-/Java-Code verwendeten Muster sind hier zentral dokumentiert. Im Code sind sie zusätzlich mit // PATTERN: markiert.
| Priorität | Pattern | Zweck | Einsatzort | Begründung |
|---|---|---|---|---|
| 10 | Hexagonal Architecture / Ports & Adapters | Fachkern von Infrastruktur entkoppeln | alle Versionen, besonders application/ports und adapters |
Enterprise-Systeme müssen Datenbank, API, Messaging und externe Systeme austauschen können. |
| 10 | Repository | Persistenz hinter fachlicher Schnittstelle kapseln | OrderRepository, InMemoryOrderRepository |
Die Application-Schicht arbeitet gegen Ports, nicht gegen Datenbankdetails. |
| 10 | Aggregate | Konsistenzgrenzen in der Domain bündeln | Order |
Geschäftsregeln liegen am fachlichen Objekt, nicht verstreut in Services. |
| 9 | Value Object | unveränderliche fachliche Werte modellieren | OrderId, Money, CustomerId |
Werte werden sicherer, testbarer und ausdrucksstärker. |
| 9 | Factory Method | gültige fachliche Objekte erzeugen | Order.open(...), OrderLine.of(...) |
Erzeugungslogik schützt Invarianten. |
| 9 | Command | Use-Case-Eingaben explizit modellieren | PlaceOrderCommand, ApproveOrderCommand |
Eingaben sind stabiler als lose Parameterlisten. |
| 9 | Application Service / Use Case | fachliche Abläufe koordinieren | PlaceOrderUseCase, ApproveOrderUseCase |
Orchestrierung bleibt getrennt von Domain-Entscheidungen. |
| 8 | Strategy | austauschbare Geschäftsregel | PricingPolicy |
Rabatte/Preise können wechseln, ohne Use Case zu verändern. |
| 8 | Adapter | externe Systeme an interne Ports anpassen | REST Controller, Persistence Adapter, Messaging Adapter | Framework-Code bleibt an der Außenseite. |
| 8 | Facade | komplexe Teilsysteme vereinfachen | OrderFacade |
API-Schicht bekommt eine stabile, einfache Oberfläche. |
| 8 | Mapper | DTOs und Domain trennen | OrderDtoMapper |
REST-/JSON-Modelle verschmutzen nicht die Domain. |
| 8 | Observer / Domain Event | Änderungen als Ereignisse ausdrücken | DomainEvent, OrderPlaced |
Nachgelagerte Prozesse können reagieren, ohne den Kern eng zu koppeln. |
| 8 | Outbox Pattern | Event-Publishing zuverlässig machen | OutboxRecord, OutboxRepository |
Datenänderung und Event werden in einer Transaktionsgrenze vorbereitet. |
| 7 | Template Method | Ablaufrahmen mit variablen Schritten | OutboxPublisherTemplate |
Wiederholbarer Publish-Prozess mit spezialisierten Implementierungen. |
| 7 | Decorator | Querschnittsfunktion ergänzen | AuditedOrderService |
Audit/Metrik kann ergänzt werden, ohne Use Case umzuschreiben. |
| 7 | Chain of Responsibility | Security-/Policy-Prüfungen verketten | ApprovalPolicyChain |
Mehrere Regeln bleiben einzeln testbar. |
| 7 | Proxy | Zugriff kontrollieren oder messen | SecuredOrderQueryProxy |
Security/Logging können vor Fachzugriff gelegt werden. |
| 7 | Specification | fachliche Auswahlregel ausdrücken | HighValueOrderSpecification |
Komplexe Filterregeln werden benannt und testbar. |
| 7 | CQRS | Schreib- und Lesemodelle trennen | V05 command und query |
Enterprise-Systeme brauchen oft andere Modelle für Schreiben, Lesen und Reporting. |
| 7 | Saga / Process Manager | verteilte Fachprozesse steuern | OrderFulfillmentSaga |
Lange Prozesse über mehrere Systeme werden nachvollziehbar orchestriert. |
| 7 | Anti-Corruption Layer | fremde Modelle abschirmen | LegacyBillingClientAdapter |
Legacy- oder Fremdsysteme sollen das eigene Domain-Modell nicht vergiften. |
| 7 | Circuit Breaker Boundary | externe Aufrufe absichern | BillingGateway |
Ausfälle externer Systeme dürfen nicht unkontrolliert in den Kern laufen. |
Grundregel
Je weiter innen eine Klasse liegt, desto weniger technische Abhängigkeiten darf sie haben. Je weiter außen eine Klasse liegt, desto stärker darf sie Frameworks, Datenbanken, Messaging oder Cloud-APIs kennen.