> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2020/w27-domain-driven-design-and-frontend-backend-interaction-patterns.md).
# W27-Domain-driven Design und die Interaktion zwischen Frontend und Backend
#### **Einige Gedanken zu Domain-driven Design**
**Wie halten wir den Kern unserer Projekte bei schnellen Veränderungen stabil, ohne dass die Komplexität mit weiteren Iterationen außer Kontrolle gerät und eine Neuentwicklung nötig wird?** Schon heute geht bei der Weitergabe im Team Geschäftswissen verloren. Mit wachsendem Team und personellen Wechseln wird das Problem nur größer. **Was ist dieser Kern? Unser Verständnis und unsere Abstraktion des Geschäfts. Auf Softwaredesign übertragen bedeutet das für mich ein domänenbasiertes Design.**
Im Vergleich zum Frontend wird das Backend meist ausführlicher und mit längerem Zeithorizont entworfen. Ein Projekt muss auf einem tiefen Verständnis des Geschäfts beruhen. Je tiefer das Verständnis und je gründlicher die Abstraktion, desto besser lassen sich Projekte warten und erweitern. In gewisser Hinsicht kann das Backend ohne Design womöglich gar nicht anfangen.
Im Frontend sieht es anders aus. Unsere technischen Konzepte betreffen überwiegend einzelne technische Fragen und die Umsetzung von Geschäftsabläufen. Bei der gründlichen Zerlegung des Geschäfts gehen wir noch nicht weit genug. Ehrlich gesagt **bleiben unsere Entwürfe im Wesentlichen auf der Ebene seitenorientierter Umsetzung**. Selten wird das Geschäft abstrahiert, um daraus Komponenten und die Schichten der Softwarestruktur abzuleiten.
In einem guten Backend-Projekt bleiben Tabellenstrukturen und Serviceschicht relativ stabil. Das verdanken sie einem tiefen Verständnis und einer guten Abstraktion der Geschäftsdomäne. Im Händlergeschäft folgen derzeit rasch neue Iterationen aufeinander. Entsprechend schnell ändern sich UI und Interaktion. Wie können wir möglichst viel Veränderung auf einer stabilen Grundlage auffangen? Wie können wir das Geschäftswachstum insgesamt günstiger unterstützen? Ich möchte Antworten im Domain-driven Design finden.
Nehmen wir den Checkout. Bei der Neuentwicklung der i-Version haben wir die gesamte Anwendung nach Container- und Darstellungskomponenten organisiert. Container übernehmen Zustandsverwaltung und Geschäftslogik. Darstellungskomponenten sind reine Komponenten, die nur Daten auf Ansichten abbilden. Die Geschäftslogik des Checkout-Frontends ist nicht besonders komplex, doch schon so umfasst der Container über 600 Zeilen. Noch wirkt das übersichtlich. Bald kommen aber Kreditzahlungen, Zahlungen aus Anlageguthaben und Marketing hinzu. Der Container wird immer umfangreicher. Was tun? Wir müssen ihn zerlegen. Nach welchem Prinzip? Nach Domänen. Im Kern behandelt das Checkout-Frontend Zahlungsarten. Wir sollten Zahlungsarten mit unterschiedlichen geschäftlichen Eigenschaften als Domänen abstrahieren. Für jede Zahlungsart stellt ein anderer Anbieter das Vermögen bereit; deshalb lässt sie sich als eigene Domäne verstehen. Jede hat besondere Eigenschaften und Verhaltensweisen. Bei der Schnellzahlung gibt es etwa eine Kartenliste und die Aktion, eine Karte auszuwählen und ein Passwort einzugeben. Bei Kreditzahlungen gibt es Laufzeit und Betrag, die Kreditaufnahme über Gesichtserkennung und das Abrufen des Kreditvertrags. Das sind die relativ stabilen Grundlagen der Geschäftslogik. Unabhängig davon, wie sich die UI später ändert, bleibt der Kern des Projekts, die Domänenschicht, bestehen. Selbst bei einem Wechsel des Frontend-Stacks von Vue zu React könnte dieser Kern stabil migriert werden.
Auch ich war beim Design bislang eher schwach. Meine Vorstellungen zu Domain-driven Design müssen sich durch weiteren Austausch und die Auseinandersetzung mit anderen Sichtweisen entwickeln.
#### **Erfahrungen mit dem Datenaustausch zwischen Frontend und Backend**
Im Vergleich zur Wallet unterscheidet sich das Zahlungsgeschäft deutlich im Entwurf der Schnittstellen zwischen Frontend und Backend. Bei Checkout, Kartenverknüpfung und Bezahlung sind die APIs für das Frontend im Wesentlichen auf Seiten zugeschnitten. Die Beziehungen zwischen den Schnittstellen folgen vollständig der zeitlichen Reihenfolge der Nutzerinteraktion. Die vorgelagerte Schnittstelle liefert die URL der nächsten Schnittstelle, deren Anfrageparameter und alles, was die aktuelle Seite benötigt. Es fehlt eigentlich nur noch die fertig gerenderte Seite.
Der Vorteil ist, dass sich die Verantwortung des Frontends weitgehend auf die Nutzerinteraktion konzentriert und damit klar abgegrenzt wirkt. Das Backend kann die Abfolge der Schnittstellen relativ flexibel steuern. Es kann die nächste Schnittstelle selbst bestimmen, unterschiedliche nachgelagerte Dienste aufrufen und schließlich Daten zurückgeben, ohne dies erst mit dem Frontend abstimmen zu müssen.
Die Nachteile sind ebenso deutlich. Das Muster koppelt API und Ansicht, beziehungsweise den Ablauf der Nutzerinteraktion, eng aneinander und ist deshalb bei Erweiterungen fragil. Diese Zusammenarbeit funktioniert, weil Frontend-Ansicht und Geschäftsablauf ausreichend stabil sind. Tatsächlich erfüllt das Zahlungsgeschäft diese Voraussetzung recht gut. Das Muster ist zwar nicht besonders universell, doch dass die Zahlungsarchitektur von Anfang an so angelegt wurde, muss auf tieferen Überlegungen beruhen. Im Zahlungskontext kann ich derzeit kein absolutes Urteil darüber fällen. Dazu brauche ich weitere praktische Erfahrung.
**Im Schnellzahlungsprojekt liefert Schnittstelle A die Adresse der nächsten Anfrage und bestimmt damit die nachfolgende Schnittstelle. Das Backend muss deshalb die Frontend-Version kennen, entweder über eine Versionsnummer oder über eine durchgängige Canary-Auslieferung anhand der Kunden-ID.**