Architekturstile, Muster und Taktiken

Warum Architekten Formen benennen

Die meisten Systeme werden nicht aus dem Nichts entworfen. Erfahrene Architekten erkennen, dass ein neues Problem einem bereits bekannten ähnelt, und greifen zu einer Form, die sich bewährt hat: ein paar Schichten für eine unkomplizierte Geschäftsanwendung, eine Kette von Verarbeitungsschritten für einen Datenfeed, ein Kern mit Plug-ins für ein Produkt, das Kunden erweitern. Diese Formen zu benennen gibt einem Team ein gemeinsames Vokabular. Der Satz es ist ein modularer Monolith mit ereignisbasierter Kommunikation zwischen den Modulen vermittelt in wenigen Worten, wofür sonst eine Seite voller Diagramme nötig wäre, und er bringt ein ganzes Wissen darüber mit, was typischerweise gut und was schiefgeht.

David Garlan und Mary Shaw stellten dies in An Introduction to Software Architecture (technischer Bericht der Carnegie Mellon University, 1994) und in ihrem Buch Software Architecture: Perspectives on an Emerging Discipline (1996) auf ein solides Fundament. Sie beschrieben einen Architekturstil als Vokabular von Komponenten- und Konnektortypen zusammen mit einem Satz von Randbedingungen dafür, wie sie kombiniert werden dürfen. Pipes and Filters hat zum Beispiel eine Art von Komponente (einen Filter, der Daten umwandelt) und eine Art von Konnektor (eine Pipe, die sie in eine Richtung transportiert), und es verlangt, dass Filter keinen Zustand teilen und ihre Nachbarn nicht kennen. Roy Fielding, dessen Dissertation (2000) REST als Stil definierte, brachte es noch schärfer auf den Punkt: Ein Stil ist ein abgestimmter Satz von Randbedingungen, und die Randbedingungen erzeugen die Eigenschaften. Verbieten Sie Filtern, Zustand zu teilen, und Sie erhalten Filter, die sich unabhängig testen, wiederverwenden und neu anordnen lassen; das ist kein Glück, sondern eine Folge der Regel.

So liest man jeden Stil in diesem und im nächsten Kapitel am besten. Ein Stil ist kein Bild zum Abzeichnen. Er ist ein Satz von Regeln, denen man zu folgen zustimmt, gewählt, weil ihre Einhaltung bestimmte Architekturmerkmale einbringt, die Qualitätsmerkmale aus Kapitel 2, zu einem Preis. Ein Team, das das Vokabular eines Stils übernimmt, aber nicht seine Regeln, zahlt den Preis ohne den Nutzen.

Stile, Muster, Taktiken und Referenzarchitekturen

Für wiederverwendbares Entwurfswissen werden vier verwandte Begriffe verwendet, oft recht locker. Sie unterscheiden sich vor allem in ihrer Reichweite und darin, wie viel sie vorschreiben.

Ein Architekturmuster beschreibt eine bewährte Lösung für ein wiederkehrendes Strukturproblem in einem bestimmten Kontext. Die Idee der Muster stammt vom Gebäudearchitekten Christopher Alexander und kam über die Entwurfsmuster von Gamma, Helm, Johnson und Vlissides (1994), die auf der Ebene weniger Klassen arbeiten, in die Software. Pattern-Oriented Software Architecture, Volume 1: A System of Patterns von Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad und Michael Stal (1996), meist POSA genannt, katalogisierte Muster auf der Ebene ganzer Systeme: Layers, Pipes and Filters und Blackboard (gruppiert als Weg vom Chaos zur Struktur, „From Mud to Structure“), Broker für verteilte Systeme, Model-View-Controller und Presentation-Abstraction-Control für interaktive Systeme sowie Microkernel und Reflection für anpassbare Systeme. Jedes POSA-Muster ist als Kontext, Problem, Kräfte und Lösung mit Konsequenzen beschrieben, was die Abwägungen explizit macht.

Eine Taktik im Sinne von Len Bass, Paul Clements und Rick Kazman in Software Architecture in Practice ist kleiner: eine Entwurfsentscheidung, die eine Reaktion eines Qualitätsmerkmals beeinflusst, etwa ein Heartbeat, um einen ausgefallenen Server zu erkennen, oder ein Cache, um die Latenz zu senken. Abschnitt 2.6 verwendete Änderbarkeitstaktiken wie Kapselung und den Einsatz eines Vermittlers. Muster bündeln mehrere Taktiken: Das Layers-Muster kombiniert Kapselung, eingeschränkte Abhängigkeiten und den Einsatz eines Vermittlers.

Eine Referenzarchitektur ist eine Vorlage für eine ganze Domäne oder Plattform: Sie benennt die typischen Bausteine und wie sie verbunden sind, sodass Projekte sie anpassen, statt mit einem leeren Blatt zu beginnen. AUTOSAR, die geschichtete Softwarearchitektur für Steuergeräte in Autos, ist ein bekanntes Beispiel; die Architecture Center der Cloud-Anbieter bieten viele kleinere. Eine Referenzarchitektur besteht meist aus mehreren Stilen und Mustern zugleich.

Fachleute sind sich nicht einig, wo die Grenze zwischen Stil und Muster verläuft. POSA nennt Layers ein Muster; Garlan und Shaw nennen Schichtensysteme einen Stil; Mark Richards und Neal Ford reservieren in Fundamentals of Software Architecture Stil für die Gesamttopologie eines Systems und Muster für wiederverwendbare Strukturen auf tieferer Ebene, die in vielen Stilen vorkommen können. Dieser Kurs folgt dem üblichen Sprachgebrauch: Stil für die Gesamtform eines Systems oder eines großen Teils davon, Muster für eine wiederverwendbare Lösung, die auf jeder Ebene sitzen kann. Verwenden Sie keine Energie auf die Grenze; verwenden Sie sie auf die Randbedingungen und ihre Folgen.

Zwei Arten, ein System zu schneiden: technische oder fachliche Partitionierung

Die erste Strukturentscheidung in jedem Stil ist, wie das System auf oberster Ebene aufgeteilt wird. Es gibt zwei grundlegende Antworten. Technische Partitionierung gruppiert Code nach technischer Rolle: alles zur Benutzeroberfläche an einem Ort, alle Geschäftsregeln an einem anderen, der gesamte Datenbankzugriff an einem dritten. Fachliche Partitionierung gruppiert Code nach Geschäftsfähigkeit: alles zu Bestellungen an einem Ort, Zahlungen an einem anderen, Lieferung an einem dritten, jeweils mit der Benutzeroberfläche, Logik und dem Datenzugriff, die dafür nötig sind.

Der Unterschied zeigt sich, sobald sich ein Feature ändert. Angenommen, ein Essenslieferunternehmen lässt Kunden ein Trinkgeld für den Kurier hinzufügen. In einem technisch partitionierten System braucht diese Änderung ein neues Feld auf einer Bildschirmmaske (Präsentation), eine neue Regel für Trinkgeldgrenzen und Auszahlungen (Geschäftslogik) sowie eine neue Spalte und Abfrage (Persistenz): drei Teile, oft im Besitz von drei verschiedenen Personen oder Teams. In einem fachlich partitionierten System landet dieselbe Änderung fast vollständig im Liefermodul. Die meisten fachlichen Änderungswünsche sind in Begriffen der Domäne formuliert, daher hält fachliche Partitionierung eine Änderung meist an einem Ort. Technische Partitionierung hält eine technische Änderung an einem Ort, etwa den Austausch der Datenbankzugriffsbibliothek, aber solche Änderungen sind seltener.

Die Wahl prägt auch die Organisation. Nach dem Gesetz von Conway wird ein technisch partitioniertes System meist von einem Frontend-Team, einem Backend-Team und einem Datenbankteam gebaut, und jedes Feature braucht eine Übergabe zwischen ihnen. Ein fachlich partitioniertes System kann von Teams gebaut werden, die jeweils eine Geschäftsfähigkeit durchgängig verantworten. Martin Fowler gab 2015 dieselbe Empfehlung: Präsentations-, Domänen- und Datenschicht sind eine gute Art, ein kleines Stück Software zu organisieren, aber die oberste Ebene eines größeren Systems sollte in domänenorientierte Module aufgeteilt werden, jedes intern in Schichten, wenn das hilft.

Keines von beiden ist falsch. Technische Partitionierung ist einfach, vertraut und wird von der Standard-Ordnerstruktur fast jedes Web-Frameworks unterstützt, und sie passt zu kleinen Systemen, in denen ein Team alles macht. Fachliche Partitionierung erfordert vorab mehr Überlegung, weil jemand gute Domänengrenzen finden muss (das Thema von Abschnitt 5.7), aber sie skaliert besser mit der Größe des Systems und der Zahl der Teams.

Monolithische und verteilte Stile

Die zweite grundlegende Unterscheidung betrifft das Deployment. Eine Deployment-Einheit ist das, was als ein Stück gebaut, released und gestartet wird: eine einzelne ausführbare Datei, ein Container-Image, ein Webarchiv. In einer monolithischen Architektur ist die ganze Anwendung eine Deployment-Einheit, meist mit einer Datenbank. Sie kann als viele identische Kopien hinter einem Load Balancer laufen, aber jede Kopie enthält den gesamten Code, und jede Änderung auszuliefern heißt, alles auszuliefern. In einer verteilten Architektur besteht das System aus mehreren Deployment-Einheiten, die zusammenarbeiten, indem sie Nachrichten über ein Netzwerk senden, und jede kann separat released und skaliert werden.

Zwei Klarstellungen vermeiden viel Verwirrung. Erstens beschreibt Monolith das Deployment, nicht die Qualität. Ein Monolith kann wunderbar modular sein oder ein Big Ball of Mud (der Name, den Brian Foote und Joseph Yoder einem System ohne erkennbare Struktur gaben), und dasselbe gilt für ein verteiltes System: Viele Teams haben gelernt, dass die Aufteilung eines Big Ball of Mud in Services einen verteilten Big Ball of Mud ergibt, und der ist schlimmer. Zweitens ist Verteilung kein kostenloses Upgrade. Jeder Aufruf über ein Netzwerk kann langsam sein, auf halbem Weg scheitern oder doppelt ankommen, Daten lassen sich nicht mehr in einer lokalen Transaktion ändern, und das System braucht Monitoring, Deployment-Automatisierung und Rufbereitschaftskompetenz, ohne die ein Monolith auskommt. Kapitel 6 behandelt diese Kosten im Detail. Dieses Kapitel behandelt die Stile, die sie vermeiden: Alles läuft in einer Deployment-Einheit, und die Architektur steckt darin, wie der Code darin organisiert ist.

Das Architekturquantum

Monolithisch und verteilt ist ein nützlicher erster Schnitt, aber zu grob für echte Entscheidungen. Neal Ford, Rebecca Parsons und Patrick Kua führten in Building Evolutionary Architectures (2017) eine schärfere Idee ein, die Ford, Richards, Sadalage und Dehghani in Software Architecture: The Hard Parts (2021) verfeinerten: das Architekturquantum. Ein Quantum ist ein Teil des Systems, der unabhängig deployt werden kann, hohe funktionale Kohäsion hat (er erledigt eine zusammenhängende Aufgabe für das Geschäft) und alles enthält, was er zum Funktionieren braucht, insbesondere seine Datenbank. Die spätere Definition ergänzt, dass die Teile eines Quantums statisch gekoppelt sind (sie teilen Code, Schemas oder Infrastruktur, die gemeinsam deployt werden müssen) und dass synchrone Aufrufe Quanten für die Dauer des Aufrufs betrieblich aneinander binden.

Warum ist das wichtig? Weil Architekturmerkmale pro Quantum gelten. Ein Quantum wird als Ganzes skaliert, deployt, abgesichert und wiederhergestellt, also hat es ein Niveau an Skalierbarkeit, ein Niveau an Verfügbarkeit, einen Release-Rhythmus. Brauchen zwei Teile eines Systems sehr unterschiedliche Merkmale, etwa ein Kurier-Standortfeed, der Tausende Aktualisierungen pro Sekunde verkraften muss, und ein monatlicher Rechnungslauf für Restaurants, dann bekommen sie diese nur, wenn sie in verschiedenen Quanten liegen. Umgekehrt entstehen durch die Aufteilung von Code in mehrere Services keine mehreren Quanten, wenn sie sich weiterhin eine Datenbank teilen: Keiner von ihnen kann das Schema ändern oder allein wiederhergestellt werden, also stehen und fallen sie gemeinsam. Ein Monolith ist per Definition ein Quantum.

Wie Sie die folgenden Stilabschnitte lesen

Die Abschnitte 5.2 bis 5.5 und der größte Teil von Kapitel 6 beschreiben jeweils einen Stil, immer in derselben Reihenfolge, damit sich die Stile vergleichen lassen: eine Definition und die Herkunft des Stils; ein Diagramm; die Funktionsweise; ein konkretes Beispielsystem; eine Tabelle, die seine wichtigsten Merkmale bewertet; wann man ihn einsetzt und wann nicht; häufige Anti-Patterns; und wie man ihn im Code durchsetzt, denn ein Stil, der nicht geprüft wird, erodiert, wie Abschnitt 1.7 beschrieben hat.

Die Merkmalsbewertungen (Niedrig, Mittel, Hoch, jeweils mit Begründung) folgen dem Ansatz der Stilvergleiche von Richards und Ford, sind aber die eigenen Einschätzungen dieses Kurses. Lesen Sie sie als relativ und typisch: Sie vergleichen Stile so, wie sie üblicherweise gebaut werden, von einem kompetenten Team, für ein typisches Geschäftssystem. Ein diszipliniertes Team kann einen Schichtenmonolithen bauen, der viele Male am Tag deployt wird, und ein nachlässiges Microservices, die sich überhaupt nicht deployen lassen. Die Bewertungen zeigen Ihnen, wo der Stil hilft und wo Sie gegen ihn arbeiten müssen.

Zwei Abschnitte in diesem Kapitel behandeln keine Deployment-Stile. Hexagonale, Onion- und Clean Architecture (Abschnitt 5.6) beschreiben, wie man das Innere einer Anwendung oder eines Service so organisiert, dass die Geschäftslogik nicht von der Technologie abhängt. Domain-Driven Design (Abschnitt 5.7) ist ein Weg, die Domänengrenzen zu finden, auf die modulare Monolithen und Microservices angewiesen sind. Beide gelten gleichermaßen innerhalb eines Monolithen wie eines verteilten Systems.

Stile lassen sich kombinieren, und sie sind keine Ziele

Reale Systeme sind Mischformen. Ein modularer Monolith kann innerhalb jedes Moduls in Schichten aufgebaut sein; eines seiner Module kann einen nächtlichen Pipes-and-Filters-Job ausführen; ein Microservice kann im hexagonalen Stil gebaut sein; ein ereignisgesteuertes System kann einen Microkernel nutzen, damit Kunden eigene Regeln hinzufügen können. Den Stil jedes Teils zu benennen ist trotzdem nützlich, weil jeder Teil dann einen bekannten Satz von Regeln und Abwägungen erbt.

Der häufige Fehler ist, einen Stil als Ziel an sich zu behandeln: Wir stellen auf Microservices um als Strategie statt als Mittel zu einer benannten Qualität wie unabhängigem Deployment für zwölf Teams. Gehen Sie von den architekturrelevanten Anforderungen aus Kapitel 2 aus, wählen Sie den einfachsten Stil, dessen Merkmale sie erfüllen, halten Sie die Wahl als Entscheidungsdokument fest und setzen Sie seine Regeln durch. Abschnitt 5.8 bietet eine Entscheidungshilfe für die Stile in diesem Kapitel.