DDD im Frontend

DDD kommt aus dem Backend. Die meisten Konzepte — Aggregate, Repositories, Domain Events, Application Services — wurden für persistente, transaktionale Systeme entwickelt. Was bleibt, wenn man sie ins Frontend überträgt?

Was gut passt

Ubiquitous Language: Das stärkste DDD-Konzept für Frontends. Wenn Entwickler, Designer und Fachexperten dieselbe Sprache sprechen, verschwindet ein ganzer Klasse von Missverständnissen.

Bounded Contexts: Im Micro-Frontend-Kontext sind Bounded Contexts die natürliche Grenze für Remotes. Tasks-Domain, Members-Domain, Dashboard-Domain — jede hat ihre eigene Sprache, ihren eigenen Zustand.

Application Services / Facades: Facade-Pattern als Application-Service-Äquivalent. Orchestriert Use-Cases ohne Domänenlogik in Infrastruktur zu ziehen.

Value Objects: Typisierte IDs, formatierte Datumswerte, berechnete Zeitspannen — als explizite Typen statt primitiver Strings.

Was schlechter passt

Aggregates mit Invarianzen: Im Frontend gibt es meist keine transaktionale Garantie. Invarianzen werden serverseitig geprüft. Das Frontend validiert — aber der Server entscheidet.

Repositories: Als Konzept ja, als vollständige Abstraktion meist Overengineering. Eine TaskService-Klasse mit klarem HTTP-Verantwortungsbereich reicht.

Domain Events im Store: Semantisch sinnvoll, aber ohne Event-Bus oft als CQRS-Pattern vereinfacht.

Das Ergebnis in Taskly

Klare Layertrennung (Presentation → Domain → Models), Facades als Applikationsschicht, Signal Store als Zustandscontainer, ViewModels statt DTOs in Komponenten. DDD als Denkwerkzeug, nicht als Framework-Implementierung.