Wann DDD im Frontend?
DDD im Frontend macht Sinn, wenn die Domänenkomplexität hoch genug ist, dass eine klare Sprache und klare Grenzen mehr wert sind als die Einfachheit eines direkten API-Mappings.
Indikatoren für DDD im Frontend
Abschnitt betitelt „Indikatoren für DDD im Frontend“- Reichhaltige Domänenlogik: Validierungen, Berechnungen, Zustandsübergänge, die nicht trivial sind.
- Geteilte Sprache zwischen Team und Domain-Experten: Wenn Entwickler und Fachexperten mit denselben Begriffen reden, ist Ubiquitous Language möglich.
- Mehrere Teams / Module: Klare Bounded Contexts verhindern ungewollte Kopplung.
- Langlebiges System: Die Investition in saubere Domänenmodellierung zahlt sich über Zeit aus.
Was DDD im Frontend konkret bedeutet
Abschnitt betitelt „Was DDD im Frontend konkret bedeutet“- Layertrennung: Präsentation → Domain → Infrastruktur (kein direktes HTTP in Komponenten)
- ViewModels statt DTOs: Die Domänenschicht übersetzt API-Strukturen in Domänenobjekte
- Facades als Applikationsschicht: Use-Cases werden durch Facades orchestriert
- Stores für Domänenzustand: NgRx Signal Store als Domänen-State-Container
Was es nicht ist
Abschnitt betitelt „Was es nicht ist“DDD im Frontend ist keine Entschuldigung für überkomplexe Infrastruktur in einfachen Fällen. Ein CRUD-Formular für Stammdaten braucht keinen Aggregate Root.