Backend- und Anwendungsarchitekturen

Backend- und Anwendungsarchitekturen

0:00 Hinter der Oberfläche liegt das Backend — und dort begegnet Ihnen ein merkwürdiges Phänomen. Fast jedes Team kann die Schichtenarchitektur aufsagen, und in fast jedem Projekt hält sie trotzdem nicht. Der Grund ist selten Unwissen. Er liegt darin, dass Schichten als Ordnerstruktur verstanden werden statt als Regel über Abhängigkeiten.

0:19 In diesem Modul schauen wir uns an, was Struktur im Backend tatsächlich leisten soll, und im zweiten Teil, wie man eine Plattform auswählt, ohne in eine Frameworkparade zu verfallen.

Backend- und Anwendungsarchitekturen

0:29 Zwei Kapitel. Im ersten geht es um Struktur: Schichten und Tiers, Ports and Adapters als Gegenentwurf, und die Frage, ob man horizontal oder vertikal schneidet. Im zweiten um die Plattformwahl — bewusst ohne Frameworkvorstellungen, dafür mit Kriterien, die Sie an Ihrer eigenen Organisation beantworten müssen. Der rote Faden bleibt derselbe wie im ganzen Seminar: Die schwer reversiblen Entscheidungen verdienen die Aufmerksamkeit.

Strukturierung des Backends

0:55 Beginnen wir mit dem Klassiker. Schichten gibt es seit Jahrzehnten, und gerade deshalb lohnt sich der genaue Blick: Was genau regeln sie eigentlich — und was regeln sie ausdrücklich nicht? Der wichtigste Satz auf dieser Folie ist der letzte: Logische Trennung erzwingt keine physische. Schichten und Tiers werden ständig verwechselt.

1:15 Eine Schicht ist eine Zuständigkeit im Code mit einer Regel über erlaubte Aufrufe. Ein Tier ist eine Maschine. Sie können vier Schichten in einem einzigen Prozess betreiben — das ist völlig in Ordnung und meistens die bessere Wahl. Die Schichtregel selbst ist denkbar einfach: Eine höhere Schicht darf eine tiefere benutzen, eine tiefere niemals eine höhere.

1:35 Fast alle Probleme entstehen dort, wo diese Richtung gebrochen wird. Achten Sie auf die Reihenfolge von oben nach unten — und besonders darauf, wo die Infrastruktur steht. In der klassischen Zeichnung liegt sie ganz unten, und die Domäne hängt von ihr ab. Genau das ist der Punkt, den die nächste Folie umdreht. Die mittleren beiden Schichten werden übrigens am häufigsten vermischt: Die Anwendungsschicht orchestriert Abläufe, die Domäne hält Regeln und Begriffe.

2:02 Wenn in Ihren Domänenobjekten Abläufe stehen, ist die Grenze weich geworden — ein frühes und gut sichtbares Warnsignal. Diese Unterscheidung wirkt akademisch, hat aber eine sehr handfeste Folge, und die steht in der Fußzeile. In der geschlossenen Variante muss jeder Aufruf durch jede Schicht — und dann entstehen Mittelschichten, die nichts tun außer weiterreichen.

2:24 Das kostet Aufwand beim Schreiben, Aufwand beim Lesen und, wenn die Schichten auf verschiedenen Maschinen liegen, echte Latenz. Die offene Variante spart das und erkauft es mit mehr Kopplung. Eine gute Regel: geschlossen als Standard, offen als begründete Ausnahme — dokumentiert, nicht stillschweigend. Jetzt die Umkehrung. Ports and Adapters dreht die Abhängigkeitsrichtung: Die Domäne kennt keine Technik mehr, sie kennt nur Ports.

2:49 Das Bild dahinter stammt aus der Welt der Geräte — ein Port ist eine Anschlussstelle, an die passende Geräte angeschlossen werden. Das erklärte Ziel des Musters ist bemerkenswert konkret formuliert: Die Anwendung soll sich von Menschen, von Programmen, von automatisierten Tests und von Stapelläufen gleichermaßen ansteuern lassen — und sich unabhängig von Geräten und Datenbanken entwickeln und testen lassen.

3:12 Die Unterscheidung in treibend und getrieben ist der Teil, den man sich merken sollte. Treibende Adapter beginnen das Gespräch — eine Oberfläche, eine Schnittstelle, ein Testrahmen. Getriebene Adapter werden angesprochen — eine Datenbank, ein Nachrichtensystem, ein Fremddienst. Diese Symmetrie erklärt, warum das Muster mit einem Sechseck gezeichnet wird und nicht mit einem Stapel: Es gibt kein Oben und Unten, nur ein Innen und ein Außen.

3:38 Dependency Inversion ist dabei das technische Mittel, nicht der Zweck. Diese vier Symptome sind deshalb so nützlich, weil man sie beobachten kann, ohne den Code zu bewerten. Wenn automatisierte Tests bei einem Umbau der Oberfläche brechen, obwohl sich fachlich nichts geändert hat, ist Fachlogik nach oben gewandert. Wenn sich ein nächtlicher Stapellauf über dieselbe Fachlichkeit nicht bauen lässt, weil sie nur über die Oberfläche erreichbar ist — dasselbe Bild.

4:04 Und der letzte Punkt ist der teuerste: Fachregeln stehen in der Datenbank und in der Anwendung, leicht unterschiedlich. Dann gibt es zwei Wahrheiten, und niemand weiß, welche gilt. Hier liegt eine Erkenntnis, die viele Teams in den letzten Jahren gemacht haben. Horizontale Schichten sind sauber, aber jede Änderung berührt alle.

4:23 Ein neues Feature heißt: eine Klasse in der Präsentation, eine in der Anwendung, eine in der Domäne, eine in der Infrastruktur — vier Orte für einen Gedanken. Vertikale Schnitte bündeln das: alles zu einem Fachthema an einem Ort, die Schichtregel gilt innerhalb weiter. Und der letzte Punkt schlägt die Brücke zu Modul acht: Genau diese Schnitte sind später die Kandidaten für eigene Dienste.

4:46 Der erste Punkt ist der, der praktisch immer zutrifft: Die Ordner heißen nach Schichten, die Abhängigkeiten halten sich nicht daran. Die Ordnerstruktur ist eine Absichtserklärung, keine Regel — und deshalb kommen wir in Modul zwölf auf automatisierte Abhängigkeitsprüfungen zurück. Der letzte Punkt beschreibt eine verbreitete Fehlaneignung: Clean Architecture wird als Ordnervorlage übernommen, inklusive der Namen, ohne die Regel dahinter.

5:11 Danach hat man mehr Ordner und dieselben Abhängigkeiten wie vorher.

Backend-Plattformen und Frameworks

5:16 Kommen wir zur Technologiewahl. Ich sage vorweg, was dieses Kapitel nicht ist: eine Vorstellung von Plattformen mit ihren Vorzügen. Wir reden über Kriterien — denn die Plattformen kennen Sie, die Entscheidungsgrundlage fehlt meistens. Ordnen wir das in unser Raster aus Modul eins ein: Die Plattformwahl steht ganz rechts, bei den schwer reversiblen Entscheidungen.

5:38 Sie bindet nicht nur Code, sondern Kompetenzen, Betriebsmodell, Bibliotheken und Ihren Einstellungsmarkt — und zwar für Jahre. Umso erstaunlicher ist, wie oft sie an einem Nachmittag fällt, oft nach der Beliebtheit einer Technologie im laufenden Jahr. Beliebtheit ist ein Datenpunkt, keine Begründung. Lesen Sie die Leitfragen in der rechten Spalte und achten Sie darauf, was ihnen gemeinsam ist: Keine einzige lässt sich technisch beantworten. Wer betreibt das in drei Jahren?

6:07 Wie verlaufen Umstiege zwischen Versionen? Finden wir Leute? Das sind Fragen an Ihre Organisation. Die einzige halbtechnische Zeile ist das Startverhalten — und die wird regelmäßig übersehen, bis jemand automatisch skalieren will und feststellt, dass der Start eine Minute dauert. Bei Kartenwerk mit seinen Lastspitzen wäre das ein ernstes Problem.

6:28 Das ist die These dieses Kapitels, und sie ist unbequem. Eine gemessen langsamere Plattform mit einem erfahrenen Team liefert früher und stabiler als die schnellere mit einem Team, das sie neu lernt. Ausfallzeiten entstehen fast nie durch zu langsame Laufzeiten, sondern durch Betriebsfehler. Und der dritte Punkt ist der, der in Rechnungen fehlt: Jede zusätzliche Plattform verdoppelt Werkzeugkette, Sicherheitsprüfungen und Bereitschaftswissen.

6:54 Technologieheterogenität wird oft als Vorteil verkauft. Sie ist ein Preis, den man aus gutem Grund zahlen kann. Damit das nicht als Dogma missverstanden wird: Es gibt gute Gründe für eine zweite Plattform, und hier stehen sie. Alle vier müssen zutreffen, nicht einer. Besonders der dritte Punkt ist entscheidend — die Grenze zwischen den Plattformen muss eine Schnittstelle sein, kein gemeinsamer Datenbestand.

7:17 Zwei Technologien auf derselben Datenbank sind keine zwei Systeme, sondern ein System mit doppeltem Werkzeugkasten. Und der vierte Punkt macht es nachprüfbar: Wenn die Entscheidung eine bewusste war, gibt es dazu einen dokumentierten Eintrag. Der letzte Punkt ist mein Favorit, weil er so einfach ist und so selten gestellt wird: Was würde der Umstieg kosten, wenn wir uns irren?

7:40 Diese Frage macht aus einer Meinung eine Risikoabschätzung. Und der zweite Punkt betrifft die Reihenfolge — die Plattform wird gewählt, bevor die Betriebsumgebung feststeht. Dabei hängt beides zusammen, wie Modul neun zeigen wird. Als Nächstes geht es um das, was zwischen den Teilen passiert: Schnittstellen und Integration.