Mit Modul 4.10 haben Sie entschieden, wie der Code innerhalb eines Programms der Kladde geschnitten ist: ein Stil, gemessen gegen vier andere, festgehalten in einem ADR und von Architekturtests im Build gehalten. Modul 4.11 geht eine Ebene höher. Es fragt nicht mehr, wie die Ordner und Projekte eines Programms aussehen, sondern wie ein ganzes System gebaut ist: wie viele Programme es gibt, wo sie laufen, wie sie miteinander sprechen und welche Daten sie teilen. Dafür gibt es Architekturstile, und um sie geht dieses Modul in der Breite: Stile, Konsistenzmodelle, Cloud-Entwurfsmuster, Ablösung alter Systeme, Micro-Frontends und Prüfungen, die die Architektur im Build halten.
Die Reihenfolge hat einen Grund. Erst haben Sie einen Stil in der Tiefe gebaut, den modularen Monolithen aus Modul 4.3, dann Stile im Code verglichen. Jetzt kommt der Vergleich der Stile für ganze Systeme, und erst danach, in Modul 4.12, schneiden Sie einen echten Dienst aus der Kladde heraus. Wer die Landkarte kennt, sieht, warum dieser eine Schritt sich lohnt und die meisten anderen nicht.
Diese Lektion zeichnet die Landkarte. Sie lernen die sechs Stile kennen, die Microsofts Azure Architecture Center beschreibt, dazu zwei weitere, die dort nicht als eigene Stile stehen. Sie sehen, woher Microservices kommen, nämlich aus SOA und ihrem Enterprise Service Bus, und was dabei schiefging. Und Sie messen, was ein Aufruf über das Netz kostet, denn das ist die Zahl, an der sich viele Stile scheiden. An der Kladde ändert sich in dieser Lektion nichts.
Drei frühere Lektionen tragen diese hier. Lektion 4.1.2 hat Qualitätsziele mit Zahlen und einer Reihenfolge aufgeschrieben, darunter den Zielkonflikt „mehr Trennung kostet Leistung, im Extremfall über das Netz“. Lektion 4.2.5 hat Conways Gesetz eingeführt. Und Lektion 4.3.6 hat im ADR „Module statt Microservices“ entschieden, dass die Kladde ein modularer Monolith ist, mit Bedingungen unter „Überprüfen, wenn“.
Was ein Architekturstil ist
Microsofts Dokumentation beschreibt einen Architekturstil als eine Familie von Architekturen mit gemeinsamen Merkmalen. Ein Stil schreibt keine Technik vor; manche Technik passt nur besser zu ihm als andere, Container etwa zu Microservices. Drei Ebenen sollten Sie dabei auseinanderhalten:
| Ebene | Frage | Beispiele | In diesem Kurs |
|---|---|---|---|
| Architekturstil | Wie ist das ganze System gebaut, aus welchen Programmen, und wie sprechen sie miteinander? | N-Tier, Microservices, ereignisgesteuert | dieses Modul |
| Code-Architektur | Wie ist der Code innerhalb eines Programms geschnitten? | Schichten, Hexagonal, Vertical Slice | Modul 4.10 |
| Entwurfsmuster | Wie löst man ein bestimmtes, wiederkehrendes Problem? | Outbox, Circuit Breaker, Cache-Aside | Modul 4.6, Lektion 4.11.5 |
Das Wichtigste an einem Stil sind seine Einschränkungen. Ein Stil legt fest, welche Bausteine es geben darf und wie sie zueinander stehen dürfen. Wer sich an diese Einschränkungen hält, bekommt bestimmte Eigenschaften dafür. Microsoft nennt als Beispiel die Einschränkungen von Microservices:
- Ein Dienst hat eine einzige Verantwortung.
- Jeder Dienst ist von den anderen unabhängig.
- Daten gehören dem Dienst, der sie besitzt; Dienste teilen keine Daten.
Daraus folgt, was man gewinnt: Dienste unabhängig ausliefern, Fehler eingrenzen, öfter ausliefern, neue Technik leichter einführen. Bricht man eine Einschränkung, etwa weil zwei Dienste doch eine Tabelle teilen, ist die Eigenschaft weg, die sie getragen hat: Die beiden Dienste lassen sich dann nicht mehr unabhängig ausliefern.
Microsofts Rat zur Wahl passt zu dem, was Sie in Modul 4.1 gemacht haben. Erst das Problem verstehen, dann die Qualitätsziele bestimmen und ordnen, dann den Stil wählen, der sie trägt. Und: mehr darauf schauen, warum man einen Stil wählt, als darauf, wie man ihn umsetzt. Wer die Gründe nicht kennt, baut leicht etwas, das von außen wie der Stil aussieht und keinen seiner Vorteile hat. Manchmal ist es besser, eine Einschränkung zu lockern, als einer reinen Lehre nachzulaufen.