Fortlaufend · neueste Einträge oben
Entwurfsmuster
Kumulative Projektdokumentation; ältere Einträge bleiben vollständig erhalten.
chronologischoffline
DDD Application Layer und Ports
Drei getrennte Application-Module mit Commands, Queries, Handlern, Projektionen und contextlokalen Ports wurden ergänzt. Payment-Provider-I/O liegt außerhalb lokaler Transaktionen; Aggregatezustand und Outbox-Übergabe bleiben lokal atomar.
- 10 Commands und 3 Queries
- 13 Handler und 3 Application Service Facades
- 13 Output Ports
- 3 Java-21-Smoke-Tests
- Architektur-Fitness-Functions
Aggregate Root, Entity, Idempotent Receiver und Domain Event
StockItem und Payment schützen getrennte Grenzen; interne Entities besitzen Lebenszyklen; stabile Identitäten verhindern Doppelwirkung.
Aggregate Root, Factory und Domain Event
Order ist Aggregate Root; OrderFactory bündelt Erzeugung; sechs Domain Events entkoppeln Folgeaktionen; Collections bleiben gekapselt.
Ubiquitous Language
| Pattern | Zweck | Einsatzort | Begründung |
|---|---|---|---|
| Ubiquitous Language | Gemeinsame, präzise Sprache für Fachseite und Umsetzung | DDD-Begriffskatalog, Sprachregeln und Gesprächsszenarien | Verhindert, dass technische oder mehrdeutige Wörter unbemerkt Architektur und Verhalten verzerren |
| Explicit Language Lifecycle | Begriffe kontrolliert vorschlagen, akzeptieren, lokal begrenzen oder veralten lassen | Sprachpflege und Entscheidungsverlauf | Fachsprache bleibt nachvollziehbar erweiterbar, ohne alte Bedeutungen still zu überschreiben |
keine vorgezogene Musterwahl
Die DDD-Variante dokumentiert in diesem Kapitel bewusst noch keine taktischen Entwurfsmuster. Muster werden erst zusammen mit begründeten Einsatzorten in späteren Kapiteln ergänzt.
ergänzte Patterns · 12. Juli 2026
| Pattern | Zweck | Einsatzort | Begründung |
|---|---|---|---|
| Assertion Helper | technische Assertions zentralisieren | SmokeAssertions | weniger Duplikation ohne versteckte Fachlogik |
| Test Utility Facade | HTTP-Testmechanik kapseln | HttpJsonClient | Fachszenarien bleiben lesbar |
| Regression Test Suite | alle Slices gemeinsam ausführen | TddCompletionRegression | sicherer Abschluss- und Refactoring-Nachweis |
| Architecture Fitness Function | Abhängigkeitsrichtung automatisieren | TddArchitectureFitnessTest | Architekturdrift früh erkennen |
| Test Suite Fitness Function | deterministische Testregeln prüfen | TestSuiteFitnessTest | Flakiness und Mock-Kopplung vermeiden |
| Mutation Probe | zentrale Regeln absichtlich verändern | Abschlusscheck | Testwirksamkeit statt nur Testanzahl messen |
ergänzte Patterns · 12. Juli 2026
| Pattern | Zweck | Einsatzort | Begründung |
|---|---|---|---|
| Repository Adapter | Ports auf PostgreSQL abbilden | tdd-technical-adapters/.../jdbc | Domänenmodell bleibt JDBC-frei |
| Unit of Work | Connection und Commit/Rollback bündeln | JdbcContext, JdbcTransactionRunner | atomare Slice-Operationen |
| Transactional Outbox | Datenänderung und Event atomar speichern | JdbcOutboxStore, OutboxEventPublisher | kein Dual-Write-Verlust |
| Polling Publisher | Outbox kontrolliert an Kafka liefern | KafkaOutboxDispatcher | at-least-once und Wiederanlauf |
| Adapter Contract Test | Portverhalten gegen reale Technik prüfen | PostgresAdapterIT | SQL-Dialekt und Constraints werden echt geprüft |
| Anti-Corruption Layer | technische/kontextuelle Daten in schmale Views übersetzen | JdbcOrderingSources, JdbcLifecycleOrderStore | Slice-Kopplung begrenzen |
Qualitäts- und Abschlussmuster
| Pattern | Zweck | Einsatzort | Begründung |
|---|---|---|---|
| Fitness Function | Architekturregeln automatisch schützen | Architekturtestmodul | Abhängigkeitsrichtung bleibt ausführbar statt nur dokumentiert |
| Test Pyramid | Tests nach Verantwortung staffeln | Domain, Application, Adapter | schnelle Fachtests und gezielte Integrationsnachweise |
| Test Double | technische Ports kontrolliert ersetzen | Application-Tests | Fehler- und Retry-Pfade reproduzierbar prüfen |
| Quality Gate | Mindestqualität als Buildregel | Maven-Profile | lokale und CI-Prüfung folgen denselben Regeln |
| Mutation Testing | Aussagekraft von Tests messen | Domain und Application | reine Zeilenabdeckung reicht nicht aus |
| Software Bill of Materials | Buildbestandteile transparent machen | CycloneDX-Aggregation | Lieferkettenanalyse vorbereiten |
| Architecture Decision Record | Entscheidungen mit Gründen konservieren | fortlaufende Entscheidungsdokumentation | spätere Änderungen bleiben nachvollziehbar |
REST und Integration
| Pattern | Zweck | Einsatzort | Begründung |
|---|---|---|---|
| Data Transfer Object | externen Vertrag vom Fachmodell trennen | rest.dto.ApiDtos | API- und Domain-Änderungen bleiben unabhängig |
| Mapper | DTOs explizit in Commands übersetzen | RestCommandMapper | keine verteilte Konvertierungslogik in Controllern |
| Thin Controller | nur HTTP-Orchestrierung | sechs REST-Controller | Fachregeln bleiben in Application und Domain |
| Exception Translator | Fachfehler als Problem Details abbilden | ApiExceptionHandler | konsistente Status- und Fehlercodes |
| Correlation Identifier | Vorgänge über Systemgrenzen verfolgen | Header, Events, Kafka-Header | Diagnose und Audit werden möglich |
| Outbox Store Port | Dispatcher von JPA entkoppeln | Ports.OutboxStore | Adapter hängen nicht voneinander ab |
| Lease / Competing Consumers | parallele Auslieferung koordinieren | JpaOutboxStore | horizontaler Betrieb ohne dauerhafte Sperre |
| Strategy | Topic-Namen kapseln | TopicNameStrategy | Namenskonvention zentral und testbar |
| Gateway Adapter | Kafka und Zahlungsanbieter anbinden | Integration-Modul | Fremdsystemdetails bleiben außen |
| Anti-Corruption Layer | Providerantworten übersetzen | HttpPaymentGateway | externes Modell dringt nicht in die Application ein |
| Composition Root | alle Implementierungen verdrahten | Bootstrap-Modul | Frameworkkopplung an einer Stelle konzentriert |
Persistence Patterns
Data Mapper, Repository Adapter, Unit of Work, Transactional Outbox, Optimistic Lock, Pessimistic Lock und Reconstitution Factory wurden im Code markiert und in der Layered-Dokumentation mit Zweck, Einsatzort und Begründung beschrieben.
12. Juli 2026 –: Layered Fachmodell und Anwendung
| Pattern | Zweck | Einsatzort | Begründung |
|---|---|---|---|
| Aggregate Root | Bestellkonsistenz schützen | domain.order.Order | Status und Positionen ändern sich kontrolliert |
| Value Object | fachliche Werte typisieren | Money, Quantity, Address, IDs, Email, SKU | verhindert Primitive Obsession |
| Snapshot | historische Werte stabilisieren | Order.Line und Invoice.Line | Katalogänderungen wirken nicht rückwirkend |
| Service Layer | Use Cases orchestrieren | sechs Application Services | Adapter erhalten einen klaren Einstieg |
| Repository | Speichertechnik abstrahieren | Application Ports | Domain und Anwendung bleiben persistenzfrei |
| Strategy | Payment Provider austauschbar machen | PaymentGateway | technische Providerwahl bleibt außerhalb der Fachlogik |
| Domain Event | fachliche Ergebnisse ausdrücken | BusinessEvent | Zustellung wird von Entscheidung getrennt |
| Idempotent Receiver | Wiederholungen sicher verarbeiten | Bestellung, Reservierung und Zahlung | verhindert doppelte fachliche Wirkung |
| In-Memory Fake | zustandsorientiert testen | InMemoryPorts | vermeidet fragile Mock-Kaskaden |
12. Juli 2026 –: Layered-Grundstruktur
| Pattern | Zweck | Einsatzort | Begründung |
|---|---|---|---|
| Value Object | validierte Bestellidentität | layered-domain / OrderId | verhindert Primitive Obsession |
| Repository | Persistenzvertrag abstrahieren | layered-application / OrderRepository | hält Technik aus der Anwendungsschicht |
| Application Service / Facade | Use-Case-Einstieg | layered-application / PlaceOrderUseCase | einheitlicher Zugriff für Eingangskanäle |
| Fitness Function | Architektur automatisch prüfen | layered-architecture-tests | verhindert schleichende Grenzverletzungen |
12. Juli 2026
Noch keine Java-Implementierung vorhanden. Ab wird jedes tatsächlich verwendete Muster direkt im Code kurz markiert und hier mit Zweck, Einsatzort und Begründung dokumentiert. Es werden keine Muster nur zu Demonstrationszwecken erfunden.