| Value Object |
Fachwerte unveränderlich und vergleichbar modellieren |
Money, OrderLine,
PriceBreakdown |
Preis-, Steuer- und Versandregeln brauchen stabile Werte ohne
Seiteneffekte. |
| Result Object |
Fachliche Entscheidungen strukturiert zurückgeben |
ValidationResult, OrderProcessingResult,
PaymentDecision |
Refactoring vermeidet Exceptions für normale
Business-Ablehnungen. |
| Strategy |
Preis-, Rabatt- und Kampagnenregeln austauschbar machen |
DiscountPolicy, VipDiscountPolicy,
CouponDiscountPolicy,
B2BVolumeDiscountPolicy |
Neue Regeln werden ergänzt, ohne die Orchestrierung zu ändern. |
| Composite Strategy |
Mehrere Strategien kontrolliert kombinieren |
PricingEngine |
Realistische Preisfindung besteht aus mehreren unabhängigen
Regeln. |
| Domain Service |
Fachlogik ausserhalb einer Entity kapseln |
ShippingCalculator, TaxCalculator,
OrderValidationService |
Logik nutzt mehrere Eingaben und gehört nicht in eine
Datenklasse. |
| Port/Adapter |
Seiteneffekte vom Kern trennen |
PaymentPort, InvoicePort,
AuditPort und Fakes |
Refactoring braucht deterministische Tests ohne echte externe
Systeme. |
| Facade/Application Service |
Use Case orchestrieren |
RefactoredOrderApplicationService |
Der neue Pfad wird lesbar und kontrolliert neben dem Legacy-Pfad
aufgebaut. |
| Factory |
konsistente Verdrahtung erzeugen |
RefactoringFactory |
Tests und Demo verwenden dieselbe Regelkonfiguration. |
| Golden Master Snapshot |
Legacy- und Refactoring-Verhalten vergleichen |
ParitySnapshot |
Sichere Migration beginnt mit beobachtbarem Verhalten. |
| Test Data Builder/Catalog |
sprechende Szenarien wiederverwenden |
OrderScenarioCatalog |
Tests beschreiben Fachfälle statt technischer Zufallsdaten. |