Entscheidungshilfe
Passung für Projektgröße, Fachkomplexität und Teamstruktur.
Entscheidungshilfe
Profil A: kleine bis mittlere Geschäftsanwendung
Empfehlung Layered, ergänzt um konsequente Tests und klare Modulregeln.
Geeignet bei stabilen Anforderungen, einem Team, gemeinsamer Datenbank und überschaubarer Fachlogik. DDD-Terminologie und Eventorchestrierung wären hier häufig teurer als ihr Nutzen.
Profil B: hohe Änderungsrate oder unsichere Anforderungen
Empfehlung TDD als Entwicklungsstandard; Architektur je nach Domänenkomplexität Layered, Modular Monolith oder DDD.
TDD-First ist besonders wertvoll, wenn Fachregeln häufig wechseln, Regression teuer ist oder technische Adapter austauschbar bleiben müssen.
Profil C: komplexe Kerndomäne und mehrere Teams
Empfehlung DDD für Sprache, Bounded Contexts und Ownership; TDD innerhalb jedes Contexts.
Geeignet, wenn unterschiedliche Fachbereiche eigene Regeln und Datenhoheit besitzen und Integrationskosten ohnehin unvermeidbar sind.
Profil D: Legacy-Modernisierung
Empfehlung mit Characterization Tests und TDD-Slices beginnen; fachliche Contextgrenzen schrittweise entdecken. Nicht sofort das gesamte System in Aggregate und Events umbenennen.
Qualitative Eignungsmatrix
| Entscheidungssituation | Layered | TDD-First | DDD |
|---|---|---|---|
| schneller Start mit bekanntem CRUD-Prozess | hoch | hoch | niedrig |
| häufig wechselnde Regeln | mittel | hoch | hoch mit TDD |
| komplexe fachliche Invarianten | mittel | hoch | sehr hoch |
| mehrere autonome Fachteamgrenzen | niedrig bis mittel | mittel | sehr hoch |
| einheitliche Datenbanktransaktion | sehr hoch | hoch | nur innerhalb eines Contexts |
| schrittweise Legacy-Ablösung | mittel | sehr hoch | hoch nach Discovery |
| geringe Betriebs- und Integrationskomplexität | sehr hoch | hoch | mittel bis niedrig |
| explizite langfristige Datenhoheit | mittel | mittel | sehr hoch |
Warnsignale
Layered nicht ausreichen lassen, wenn
- Services fachlich unzusammenhängende Regeln sammeln,
- jede Änderung viele technische Schichten gleichzeitig berührt,
- mehrere Teams dieselben Tabellen und Entitäten verändern.
TDD nicht missverstehen
- Tests ersetzen keine strategische Architekturentscheidung,
- ein grüner lokaler Test beweist keine gute Contextgrenze,
- zu viele Mocks können das Design verschlechtern.
DDD nicht einsetzen, wenn
- die Domäne überwiegend CRUD und Workflow-Konfiguration ist,
- keine Fachpersonen an Sprache und Modell mitarbeiten,
- Team und Betrieb die zusätzlichen Verträge nicht tragen können.
Schlussentscheidung
Für das Labor ist keine Variante pauschal besser. Die sinnvollste Enterprise-Zielarchitektur wäre eine modulare, fachlich geschnittene Anwendung mit DDD dort, wo die Domäne komplex ist, TDD als durchgängiger Entwicklungsweise und Layering/Ports als technische Abhängigkeitsregel.