Modulgrenzen und Abhängigkeiten
Technische Schichten, testgetriebene Slices und Bounded Contexts.
Modulgrenzen und Abhängigkeitsrichtung
Layered
Die sieben Module folgen technischen Verantwortungen: Domain, Application, Persistence, Integration, REST, Bootstrap und Architecture Tests. Der zentrale Vorteil ist eine sofort erkennbare Aufrufrichtung. Der zentrale Risikopunkt ist, dass fachlich unabhängige Bereiche über gemeinsame Application Services oder ein gemeinsames Datenmodell gekoppelt werden.
REST ──> Application ──> Domain
^
Persistence ───┘
Integration ───┘
Bootstrap komponiert alle AdapterTDD-First
Die drei Module bündeln Walking Skeleton, technische Adapter und Qualität. Innerhalb des Walking Skeletons liegen vertikale fachliche Slices und Ports. Die Modulzahl ist klein, während die Zahl der schmalen Klassen hoch ist. Die Grenzen entstanden nicht zuerst als Organigramm, sondern wurden nach wiederkehrenden Test- und Refactoring-Signalen herausgearbeitet.
Acceptance Test ──> Use Case ──> Port
^ |
HTTP Handler ────────────┘ └── AdapterDDD
Dreizehn Module bilden Value Objects, Aggregate, drei Domain- und drei Application-Bereiche, Integrationsverträge, Adapter, Workflow und Kontexttests ab. Die Abhängigkeitsrichtung ist pro Bounded Context lokal. Kontextübergreifende Zusammenarbeit erfolgt über veröffentlichte Verträge und einen Process Manager.
Ordering Application ──> Ordering Domain
Inventory Application ─> Inventory Domain
Payment Application ───> Payment Domain
|
└── Published Language / Outbox / Process ManagerVergleich
| Kriterium | Layered | TDD-First | DDD |
|---|---|---|---|
| primäre Grenze | technische Schicht | testgetriebener Slice und Port | Bounded Context und Aggregate |
| kleinste Änderungseinheit | Service plus Adapter | Use Case Slice | fachliche Fähigkeit im Context |
| Datenhoheit | häufig zentral | je Port pragmatisch | explizit je Context |
| verbotene Kopplung | äußere zu falscher Schicht | Test-/Adapterdetails zum Kern | direkte Context-zu-Context-Modellkopplung |
| typische Gefahr | horizontale Änderung durch viele Schichten | zu viele schmale Typen oder testgetriebene Lokallösung | hohe Modellierungs- und Integrationskosten |
Bewertung
Layered besitzt die geringste Einstiegshürde. TDD-First reduziert Änderungsangst und lässt Grenzen aus Verhalten entstehen. DDD liefert die stärksten fachlichen Ownership-Grenzen, verlangt aber konsequente Sprache, Integration und Governance.