← Zurück

Design Patterns in Transaktionen & ACID

Pattern Zweck Einsatzort Begründung
Value Object fachliche Werte unveränderlich modellieren Money, OrderId, ProductId, OrderLine stabile Gleichheit, keine Seiteneffekte, gut testbar
Aggregate Root Konsistenz innerhalb einer fachlichen Grenze schützen Order Statusübergänge und Lines werden zentral kontrolliert
Repository Speichertechnik hinter fachlicher Schnittstelle verstecken OrderRepository, OutboxRepository Application Service kennt keine konkrete DB
Port/Adapter Infrastruktur austauschbar machen InventoryPort, EventBroker, InMemory-Adapter Code bleibt framework- und brokerneutral
Application Service Use Case und Transaction Boundary definieren SafeOrderApplicationService Controller/Adapter sollen keine Transaktionslogik enthalten
Unit of Work Änderungen sammeln und atomar anwenden Transaction, TransactionManager Commit/Rollback wird sichtbar und testbar
Outbox Dual-Write-Problem entschärfen OutboxMessage, OutboxPublisher Event wird mit Fachzustand committed und später gesendet
Fake Adapter Tests ohne externe Systeme ermöglichen InMemoryEventBroker, InMemory-Repositories Verhalten ist deterministisch und schnell prüfbar
⌂ Cockpit