Architekturstile I: Monolithen und modulare Designs

Willkommen zu Kapitel 5: Architekturstile, Teil eins, Monolithen und modulare Designs. Die meiste Software, darunter einige der größten und erfolgreichsten Produkte, läuft als eine einzige deploybare Anwendung. Dieses Kapitel erklärt, wie solche Anwendungen im Inneren strukturiert sein sollten und wann eine einzige Anwendung die richtige Antwort ist.

Die Kapitel 3 und 4 haben Ihnen die Prinzipien guter Struktur und die Werkzeuge zu ihrer Beschreibung vermittelt. Dieses und das nächste Kapitel machen daraus die wiederkehrenden Formen, die reale Systeme annehmen. Wer die wichtigsten Stile kennt, kann von einer bewährten Form für bestimmte Qualitäten ausgehen, sie in einem Satz erklären und früh erkennen, wann ein System von ihr abdriftet. Dieses Kapitel behandelt Stile, bei denen die ganze Anwendung eine Deployment-Einheit ist: ein Build, ein Release, meist eine Datenbank. Primitiv sind Monolithen deshalb nicht. Ob die Arbeit an einem Monolithen Freude oder Qual ist, hängt fast vollständig davon ab, wie er im Inneren aufgeteilt ist.

Das Kapitel richtet sich an Entwicklungsteams und Architekten, die Geschäftsanwendungen entwerfen oder warten und eine Struktur bewusst wählen und durchsetzen wollen. Es baut auf den Kapiteln 3 und 4 auf, insbesondere auf Modularität, Kopplung und Kohäsion, Abhängigkeiten und Schichtenbildung sowie dem C4-Modell. Die Qualitätsmerkmale aus Kapitel 2 werden durchgehend verwendet. Und es führt zu Kapitel 6, das dieselben Fragen über ein Netzwerk trägt, wo alles schwieriger wird. Ein Monolith vermeidet die Netzwerkfehler, Teilausfälle und Konsistenzprobleme verteilter Systeme. Diesen widmet sich Kapitel 6.

Zuerst eine Definition. Ein Architekturstil ist ein benannter Satz von Randbedingungen dafür, welche Arten von Teilen ein System hat und wie sie verbunden sein dürfen. Auf die Randbedingungen kommt es an. Verbieten Sie etwa einem Geschäftsmodul, die Tabellen eines anderen anzufassen, und Sie erhalten vorhersagbare Vorteile zu einem vorhersagbaren Preis.

Das Kapitel hat acht Abschnitte. Abschnitt fünf Punkt eins legt das Vokabular für jeden Stil in den Kapiteln 5 und 6 fest: Stile, Muster, Taktiken und Referenzarchitekturen. Er erklärt den Unterschied zwischen technischer Partitionierung nach Schicht und fachlicher Partitionierung nach Geschäftsfähigkeit. Und er führt das Architekturquantum ein: einen unabhängig deploybaren Teil samt Daten, für den ein Satz von Qualitäten gilt.

Darum ist die Partitionierung wichtig. Angenommen, ein Essenslieferunternehmen lässt Kunden ein Trinkgeld für den Kurier hinzufügen. Bei technischer Partitionierung betrifft diese eine Änderung die Präsentationsschicht, die Geschäftslogik und die Persistenzschicht. Bei fachlicher Partitionierung landet dieselbe Änderung fast vollständig im Liefermodul, das intern trotzdem in Schichten aufgebaut sein kann. Die meisten fachlichen Änderungswünsche sind in Begriffen der Domäne formuliert, daher hält fachliche Partitionierung eine Änderung meist an einem Ort. Und sie lässt jedes Team eine Geschäftsfähigkeit durchgängig verantworten.

Die Abschnitte fünf Punkt zwei bis fünf Punkt fünf beschreiben vier Stile im gleichen Format, mit Diagramm, Beispiel, Merkmalstabelle, Einsatzempfehlung und Durchsetzung im Code. Die Schichtenarchitektur ist der vertraute Stapel aus Präsentations-, Geschäfts- und Persistenzschicht. Der modulare Monolith teilt eine deploybare Anwendung nach Fachdomänen auf, mit expliziten Modulschnittstellen und klarer Datenhoheit, veranschaulicht an den Erfahrungen von Shopify. Pipes and Filters ordnet die Verarbeitung als Kette unabhängiger Schritte an, von Unix-Pipes bis zu Datenpipelines. Und der Microkernel baut einen minimalen Kern, den Plug-ins erweitern, wie bei Entwicklungswerkzeugen, Browsern und Regel-Engines.

Dieses Diagramm aus Abschnitt fünf Punkt drei zeigt einen modularen Monolithen von innen. Die gestrichelte Grenze ist eine Deployment-Einheit: die Essensliefer-Anwendung. Jedes Modul, hier Bestellungen und Zahlungen, hat eine kleine öffentliche API. Bestellungen darf Zahlungen nur über diese API nutzen. Alles andere in einem Modul ist intern. Aus den Interna eines Moduls in die eines anderen hineinzugreifen ist verboten. Und jedes Modul besitzt sein eigenes Schema, ohne Joins über Schemagrenzen hinweg. Halten Sie sich an diese Regeln, und jedes Modul lässt sich später mit überschaubarem Aufwand in einen Service herauslösen.

Abschnitt fünf Punkt sechs behandelt hexagonale, Onion- und Clean Architecture. Sie stellen die Geschäftslogik ins Zentrum und machen Datenbanken, Benutzeroberflächen und externe Dienste von ihr abhängig, nie umgekehrt. Abschnitt fünf Punkt sieben zu strategischem Domain-Driven Design liefert die Methode, um gute Grenzen zu finden: Subdomänen, Bounded Contexts und ihre Beziehungen in einer Context Map. Schließlich fragt Abschnitt fünf Punkt acht, wann ein Monolith die richtige Antwort ist, wie weit er skalieren kann und welche Anzeichen sagen, dass es Zeit für eine Aufteilung ist. Er endet mit einer Entscheidungshilfe und einer Vergleichstabelle für alle Stile des Kapitels.

Wenn Sie sich nur eines merken, dann dies: Die Grenzen innerhalb eines Systems sind wichtiger als die Grenzen zwischen Deployment-Einheiten. Services, die sich eine Datenbank teilen und gegenseitig ihre Interna aufrufen, sind immer noch ein verworrenes System, nun zusätzlich mit Netzwerkfehlern. Daraus folgen zwei Gewohnheiten. Erstens: Wählen Sie den einfachsten Stil, dessen Merkmale die architekturrelevanten Anforderungen erfüllen, und halten Sie Wahl und Abwägungen in einem Entscheidungsdokument fest. Zweitens: Setzen Sie die Regeln des Stils mit Architekturtests im Build durch, denn jeder Stil erodiert, wenn seine Randbedingungen nur in den Köpfen existieren.

Lesen Sie zuerst Abschnitt fünf Punkt eins, denn jeder spätere Abschnitt nutzt sein Vokabular. Danach können Sie die Stile der Reihe nach durchgehen oder gezielt den lesen, den Sie brauchen. Das Kapitel zu lesen dauert etwa drei Stunden. Verfolgen Sie die Essenslieferplattform, die sich durch das ganze Kapitel zieht. Stile an einem vertrauten System zu vergleichen ist viel leichter als an zusammenhanglosen Spielzeugbeispielen. Jeder Abschnitt endet mit einigen Fragen zur Selbstkontrolle. Beantworten Sie sie im Kopf, bevor Sie nachsehen. Wenn Sie so weit sind, legen Sie den optionalen Kapiteltest ab: zwanzig Multiple-Choice-Fragen und zwei schriftliche Antworten, in etwa fünfundvierzig Minuten. Die Bestehensgrenze liegt bei achtzig Prozent.

Das ist der Überblick über Kapitel 5. Beginnen Sie mit Abschnitt fünf Punkt eins, wo wir das Vokabular von Stilen, Mustern und Taktiken festlegen, auf das die nächsten beiden Kapitel aufbauen. Bis gleich.