Domain-Driven Design im Frontend: Strategien für Single Page Applications

In der Geschichte der Softwareentwicklung gibt es zwei sich beständig abwechselnde Paradigmen: „Thin Client“ (d. h., der Code läuft hauptsächlich auf einem Server, die Clients sind leistungsschwach) und „Fat Client“ (d. h., der Client ist in der Lage, ganze Anwendungen auszuführen). Gab es ursprünglich nur Server mit Terminals, brachte der PC die Wende hin zum lokalen Arbeitsgerät, doch der Siegeszug des Webs sorgte dafür, dass so mancher PC nur noch dazu benutzt wurde, mithilfe des Browsers Webseiten anzuzeigen, die auf einem leistungsfähigen Server erstellt worden waren. Doch auch hier endete die Entwicklung nicht, denn Frameworks und Libraries wie Angular oder React ermöglichten wieder einmal die Verlagerung von Code in den Client, diesmal in Gestalt von Single Page Applications mit dem Browser als Ausführungsplattform. Dieser Artikel möchte beleuchten, wie sich Domain-Driven Design in einer solchen Single Page Application etablieren lässt und wie sich die verschiedenen DDD-Konzepte übertragen lassen.

Strategic Patterns

Die Strategic Patterns in DDD dienen dazu, die verschiedenen fachlichen Teilbereiche – genannt Subdomänen – einer Applikationslandschaft herauszuarbeiten und die bei der Umsetzung entstehenden Bounded Contexts voneinander abzugrenzen und zu trennen. Diese Trennung kann unterschiedlich realisiert werden, angefangen bei der Verabredung, bestimmte Codebereiche innerhalb eines Monolithen voneinander zu isolieren (man spricht in diesem Zusammenhang auch von einem Modulithen), bis hin zur tatsächlichen physischen Aufteilung in separate Deployment-Einheiten, die dann je nach Größe als Microservices oder Self-contained Systems bezeichnet werden. Die allgemein verbreitete Idee ist, dass jeder Bounded Context seine eigenen UI-Bestandteile mitbringt, sodass jedes dieser Frontends auf natürliche Weise nur zu einem Bounded Context gehört und keine weitere Untergliederung dieser Frontends mehr erforderlich ist.

Wenn wir allerdings über eine Single Page Application als quasi einzige Implementierung sprechen, d. h., wenn das Backend nur eine sehr untergeordnete Rolle spielt, ist es durchaus möglich, dass diese SPA groß genug ist, um in mehrere Bounded Contexts unterteilt zu werden. Da es ja mittlerweile auch Modularisierungstechniken von Frontend-Code inklusive Lazy Loading gibt, steht dem auch auf technischer Seite nichts im Weg. Wie wir in einer solchen SPA herausfinden, wie die Bounded Contexts geschnitten werden sollen, erfolgt genauso wie beim Backend durch ein gemeinsames Knowledge Crunching aller Projektbeteiligten unter Verwendung eines der etablierten Modellierungsverfahren.

Tactical Patterns

Die Tactical Patterns stellen Entwicklungsmuster bereit, die innerhalb eines Bounded Context zum Einsatz kommen. Im Folgenden gebe ich einen kurzen Überblick über die wichtigsten Themen im Zusammenhang mit Tactical Patterns und wie sie im Frontend umgesetzt werden können.

Die Domäne ist frei von technischem Code

Domain-Driven Design verfolgt den Grundsatz, dass die Domänenlogik technikfrei sein muss, damit der Code sich vollständig auf die Domänenlogik fokussieren kann. Das hilft einerseits beim Verstehen und der Wartung des Codes und erlaubt andererseits die leichtere Austauschbarkeit von technischem Code, insbesondere Libraries oder Frameworks von Drittanbietern. In diesem Zusammenhang wird oft davon gesprochen, dass die Domänenlogik im „Zentrum“ oder im „Herzen“ der Software sitzt, während der technische Code nach „außen“ geschoben wird. Architekturmuster wie Hexagonal Architecture (auch Ports and Adapters genannt) folgen ebenfalls diesem Bild. Die Interaktion erfolgt dabei nur von außen nach innen, d. h., technischer Code benutzt den Domänencode, aber der Domänencode darf technischen Code nicht direkt aufrufen, damit diese strikte Trennung erhalten bleibt.

Im Frontend ist diese Abgrenzung bei weitem nicht so scharf, da hier ja auch die Repräsentation von Daten integraler Bestandteil ist, und diese Repräsentation ist natürlich ein technischer Aspekt. Benutzt man außerdem eine Technologie, bei der Code und Repräsentation sehr eng gekoppelt sind, wie das zum Beispiel bei React mit JSX der Fall ist, ist eine hundertprozentige Trennung kaum möglich. Trotzdem kann man auch in einem solchen Umfeld viel erreichen, wenn man die Geschäftslogik nicht direkt in den Komponenten implementiert, sondern sie in eigene Funktionen (in separaten Dateien) auslagert, die dann in den Komponenten aufgerufen werden. Das macht übrigens auch das Testen deutlich einfacher.

Ein weiterer technischer Aspekt, den man in Frontends so gut wie immer findet, ist die Kommunikation mit dem Backend. Auch hier ist es wichtig, die Technik von der Fachlichkeit zu trennen, also die eigentliche Anfrage (also welche Technologie zum Einsatz kommt, welche Implementierung dafür verwendet wird etc.) inklusive der erforderlichen Konfiguration zu kapseln und vom Domänencode zu trennen.

Der Code ist fachlich gruppiert, nicht technisch

Gemäß DDD wird der Code so organisiert, dass fachlich zusammengehörender Code nah beieinander abgelegt wird. Das hat mehrere Vorteile: Zum einen lässt sich so rasch erfassen, wo man nach dem Code suchen muss, der ein bestimmtes Feature umsetzt, sodass man sich auch in fremden Codebasen relativ leicht zurechtfinden kann. Des Weiteren beschränkt eine derartige Organisation die Änderungen, die bei der Anpassung eines einzelnen Features entstehen, auf wenige Verzeichnisse und verhindert das sogenannte „Shotgun Surgery“-Antipattern (also wörtlich „Operation mit der Schrotflinte“), bei dem Änderungen für ein einzelnes Feature gleichmäßig über die gesamte Codebasis verteilt sind – ganz so, als hätte man mit einem Schrotgewehr auf den Code geschossen. Das hilft insbesondere, Merge-Konflikte zu vermeiden, wenn im Team gleichzeitig an verschiedenen Features gearbeitet wird. Auch im Frontend lässt sich eine solche fachliche Organisation des Codes leicht durchführen.

Entities, Value Objects etc.

In Domain-Driven Design gibt es verschiedene Muster, nach denen der Code für einzelne Objekte umgesetzt werden sollte. Die Häufigsten sind dabei Entities und Value Objects. Bei den Entities handelt es sich um Objekte, die einen Lebenszyklus haben, in dessen Verlauf sich die Daten der Entity ändern können. Trotzdem ist dieses Objekt zu jeder Zeit eindeutig über einen Identifikator erkennbar. Bei einer Person können sich z. B. Name, Adresse oder Geschlecht ändern, aber mit Hilfe eines Identifikators, wie z. B. einer Kunden- oder der Steuernummer, lässt sich immer zweifelsfrei das richtige Objekt zuordnen.

Im Gegensatz dazu haben Value Objects keinen separaten Identifikator, sie sind nur über die enthaltenen Daten identifizierbar. Sind die Daten anders, muss es sich um ein anderes Value Object handeln. Daraus abgeleitet findet die Umsetzung als unveränderliches, „immutable“ Objekt immer größere Verbreitung. Man kann diese Umsetzung im Frontend entweder durch Libraries erzwingen oder sich selbst so weit disziplinieren, dass die entsprechenden Objekte nicht mutiert werden. Auch Bibliotheken, wie z. B. Redux, setzen voraus, dass der Store immutable ist, dass bei Änderungen also jedes Mal ein neuer Store erzeugt wird. Es ist also durchaus sinnvoll, sich an dieses Entwicklungsmuster zu gewöhnen. Es hilft bei der Fehlervermeidung und erleichtert das Testen und sollte daher eingesetzt werden, wo immer es möglich ist.

Aggregate

Ein Aggregat in DDD bildet einen Workflow ab und kümmert sich um alles, was damit zusammenhängt. Es bildet eine Transaktionsgrenze (d. h., alle geänderten Daten werden gemeinsam persistiert) sowie eine Konsistenzgrenze (d. h., alle Daten innerhalb des Aggregats müssen zu jeder Zeit gemäß der Regeln der Geschäftslogik konsistent sein).

Üblicherweise enthält ein Bounded Context mehrere Aggregate, was zu einer Modularisierung des Codes führt.

Im Frontend sind die Nutzerinteraktionen naturgemäß viel kleinteiliger als in einem Backend-Aggregat, das mit einem Aufruf einen gesamten Workflow abarbeiten sollte. Daher werden wir im Frontend in den seltensten Fällen ein vollständiges Aggregat vorfinden.

Allerdings können wir uns auch hier die Erkenntnisse von DDD zunutze machen, indem wir die relevanten Aspekte von Aggregaten nachbilden. Denn auch im Frontend haben wir ja Workflows in Gestalt der verschiedenen Seiten der Applikation bzw. der verschiedenen Teilbereiche einer Seite, auch wenn diese bei der Implementierung in viele Einzelaktionen des Benutzers zerfallen.

Daher können wir in unseren „Frontend-Workflows“ den hierfür notwendigen Domänencode zusammenfassen (z. B. in einer entsprechend benannten Datei oder in einem Verzeichnis) und ihn als eine Einheit betrachten. Und auch im Frontend können wir die Konsistenz der Daten gemäß der Geschäftslogik durch geeignete Prüffunktionalität sicherstellen. Als Transaktionsgrenze kann zum Beispiel die Übertragung eingegebener Daten ins Backend angesehen werden. Auf diese Weise haben wir zwar nicht unmittelbar Aggregate implementiert, aber zumindest werden wichtige Eigenschaften der Aggregate nachgebildet.

Fazit

Auch wenn Domain-Driven Design normalerweise lediglich mit Blick auf das Backend betrachtet wird, lassen sich doch auch für das Frontend viele nützliche Entwicklungsmuster ableiten. So können Single Page Applications im Hinblick auf Verständlichkeit, Erweiterbarkeit und Wartbarkeit ähnlich gut umgesetzt werden wie reine Backend-Software.

Frequently Asked Questions (FAQ)

1. Was bedeutet Domain-Driven Design (DDD) im Kontext des Frontends? Domain-Driven Design im Frontend beschreibt die Ausrichtung der Architektur, Logik und Komponentenstruktur einer Anwendung an der fachlichen Domäne, um Fachlichkeit und Technik eng miteinander zu verbinden.

2. Warum ist DDD für Single Page Applications (SPA) relevant? Bei SPAs ermöglicht DDD eine klare Trennung fachlicher Bereiche und fördert die Wartbarkeit, Skalierbarkeit und Verständlichkeit komplexer Anwendungen.

3. Wie wird die Domäne im Frontend abgegrenzt? Die Abgrenzung erfolgt über fachliche Kontexte, sogenannte „Bounded Contexts“, die jeweils eigene Modelle, Zustände und Komponenten besitzen.

4. Welche Rolle spielen Module und Komponenten in einem DDD-basierten Frontend? Module und Komponenten bilden die technischen Entsprechungen der fachlichen Domänenmodelle und helfen, die Fachlogik klar zu strukturieren und wiederverwendbar zu gestalten.

5. Wie kann die Kommunikation zwischen den Domänen organisiert werden? Die Kommunikation erfolgt über definierte Schnittstellen und Events, um Abhängigkeiten zu minimieren und die Eigenständigkeit der Kontexte zu erhalten.

6.Welche Herausforderungen entstehen bei der Umsetzung von DDD im Frontend? Herausforderungen liegen in der Synchronisation zwischen Backend- und Frontend-Domänen, der Komplexität verteilter Zustände und der Notwendigkeit konsistenter Begriffe.

7. Welche Vorteile bietet ein domänenorientiertes Frontend langfristig? Ein solches Frontend erleichtert die Weiterentwicklung, reduziert technische Schulden und verbessert die Zusammenarbeit zwischen Entwicklung und Fachabteilung.

8. Wie unterstützt DDD die Entwicklung von großen Frontend-Systemen? DDD ermöglicht eine skalierbare Struktur durch klare Verantwortlichkeiten, modulare Architektur und eine enge Kopplung von Fachlichkeit und Code.

Nicole Rauch

Nicole Rauch ist freiberufliche Softwareentwicklerin und Softwareentwicklungscoach mit umfangreichem Hintergrund in Compilerbau und formalen Verifikationsmethoden. Neben Specification by Example, Domain-Driven Design, React.js/Redux, Node.js und der Sanierung von Java Legacy Code Applikationen erobern funktionale Programmiersprachen, allen voran Haskell, sich langsam aber sicher einen festen Platz in ihrem Repertoire. Des weiteren wirkte sie an der Ausrichtung mehrerer selbstorganisierter Konferenzen und an der Initiierung der Softwerkskammer, einer deutschsprachigen User Community zum Thema Software Craftsmanship, sowie ihrer Karlsruher Regionalgruppe mit. Sie hat zusammen mit Michael Sperber das iSAQB-Curriculum „Funktionale Software-Architektur“ entwickelt.