| Value Object |
fachliche Werte unveränderlich modellieren |
Money, OrderId, CustomerId,
ProductId, OrderLine |
stabile Gleichheit, keine verdeckte Identität, sicher in
Maps/Sets |
| Aggregate Root |
Invarianten und Statusübergänge schützen |
Order |
Bestellung bleibt konsistent; Events entstehen aus
Domain-Zustand |
| Repository |
Persistenz als Collection-artige Schnittstelle kapseln |
OrderRepository, CustomerRepository |
Use Case kennt keine Datenbankdetails |
| Port/Adapter |
Infrastruktur vom Anwendungskern trennen |
InventoryPort, PaymentPort,
InMemory...Adapter |
externe Systeme austauschbar und testbar |
| Application Service |
Use Case orchestration ohne Fachlogik-Versteck |
OrderApplicationService |
Transaktionsgrenze, Ports und Outbox werden klar koordiniert |
| Strategy |
veränderliche Preislogik kapseln |
PricingPolicy, DefaultPricingPolicy |
Rabatte/Segmente wachsen ohne Monster-Methode |
| Domain Service |
fachliche Berechnung außerhalb eines einzelnen Aggregats |
PricingService |
Pricing betrifft Customer und Lines gemeinsam |
| Result Type |
fachliche Fehler explizit zurückgeben |
Result, DomainError |
API/Use Case kann Fehler vollständig behandeln |
| Unit of Work Boundary |
Transaktionsgrenze fachlich sichtbar machen |
TransactionRunner |
Anwendung steuert Grenze, Adapter setzt Technik um |
| Transactional Outbox |
Dual-Write-Problem entschärfen |
OutboxMessage, OutboxRepository,
OutboxPublisher |
Commit und späteres Publizieren werden entkoppelt |
| Idempotent Consumer |
doppelte Events schadlos machen |
IdempotencyStore, ReportingConsumer |
Broker/Publisher können Events mehrfach liefern |
| Data Mapper |
Domain von relationaler Form trennen |
OrderDataMapper, OrderRow |
JPA/JDBC-Mentalmodell wird sichtbar |
| Identity Map |
geladene Zeilen im Context stabilisieren |
PersistenceContext |
Grundlage für Persistence Context und Dirty Checking |
| Fake |
Tests ohne echte Fremdsysteme |
FakePaymentAdapter, Memory-Repositories |
deterministisch, schnell, ohne Netzwerk |