Handbuch moderner Softwarearchitektur

Architekturstile, Patterns und Best Practices

Mark Richards, Neal Ford

• Publisher: O'Reilly
• Year: 2020
• ISBN:
  9783960104308
• Topic: Informatik
• Subtopic: Softwareentwicklung

Softwarearchitektur zeitgemäß und pragmatisch geplant

• Architektonische Muster: Das technische Fundament für viele architektonische Entscheidungen
• Komponenten: Identifizierung, Kopplung, Kohäsion, Partitionierung und Granularität
• Architekturstile wie Microkernel, SOA, Microservices u.v.m. und ihre architektonischen Eigenschaften
• Softwarearchitektur als Engineering-Disziplin: mit wiederhol- und messbaren Ergebnissen zu stabilen Architekturen

Mark Richards und Neal Ford — Praktiker mit Erfahrung aus erster Hand, die seit Jahren das Thema Softwarearchitektur unterrichten —, betrachten Softwarearchitektur vor dem Hintergrund der Entwicklungen, Innovationen und Herausforderungen des letzten Jahrzehnts. Sie konzentrieren sich auf Architekturprinzipien, die für alle Technologie-Stacks gelten.
Angehende und erfahrene Architekten finden in diesem Buch umfassende Informationen zu architektonischen Merkmalen und Architekturstilen, zur Bestimmung von Komponenten, zur Diagrammerstellung und Präsentation, zu evolutionärer Architektur und vielen weiteren Themen.
Die Autoren verstehen Softwarearchitektur als Engineering-Disziplin: mit wiederhol- und messbaren Ergebnissen und konkreten Kennzahlen für stabile Softwarearchitekturen.

KAPITEL 1

Einleitung

Die Berufsbezeichnung »Softwarearchitekt« steht auf vielen Listen der besten Jobs auf der ganzen Welt ganz oben. Für die anderen Berufe auf der Liste (zum Beispiel Krankenpfleger oder Finanzmanager) gibt es einen klaren Karrierepfad. Warum gibt es keinen Karrierepfad für Softwarearchitekten?

Zunächst einmal hat die Branche selbst keine gute Definition von Softwarearchitektur. Wenn wir Grundlagenkurse unterrichten, fragen die Studenten oft nach einer klaren Definition für das, was ein Softwarearchitekt tut. Bisher haben wir ihnen diese Antwort hartnäckig verweigert. Und damit sind wir nicht alleine. In seinem berühmten Whitepaper »Who Needs an Architect?« (https://oreil.ly/-Dbzs) weigerte sich Martin Fowler bekanntlich, auch nur zu versuchen, den Begriff »Softwarearchitekt« zu definieren. Stattdessen wich er auf das folgende berühmte Zitat aus:

Bei der Softwarearchitektur geht es um wichtige Dinge … welche auch immer das sind.

– Ralph Johnson

Erst unter Druck haben wir die in Abbildung 1-1 gezeigte Mindmap erstellt. Sie ist hoffnungslos unvollständig, zeigt aber, wie groß das Feld der Softwarearchitektur tatsächlich ist. In Kürze werden wir Ihnen unsere eigene Definition der Softwarearchitektur vorstellen.

Außerdem zeigt die Mindmap, dass die Rolle des Softwarearchitekten sehr viele Verantwortungsbereiche umfasst, die immer weiter wachsen. Noch vor zehn Jahren haben sich Softwarearchitekten nur mit den rein technischen Aspekten der Architektur befasst, wie Modularität, Komponenten und Patterns. Durch neue Architekturstile, die zusätzliche Möglichkeiten (zum Beispiel Microservices) nutzen, hat sich auch die Rolle des Softwarearchitekten erweitert. Die vielen Überschneidungen zwischen der Architektur und dem Rest des Unternehmens betrachten wir in »Überschneidungen von Architektur und …« auf Seite 13.

Durch die fortschreitende Evolution der Softwareentwicklung ist auch die Softwarearchitektur ständig in Bewegung. Jede heute gültige Definition wird schon in ein paar Jahren hoffnungslos veraltet sein. Die Wikipedia-Definition der Softwarearchitektur (https://de.wikipedia.org/wiki/Softwarearchitektur) gibt hier einen guten Überblick.

Abbildung 1-1: Die Verantwortlichkeit eines Softwarearchitekten umfasst technische Fähigkeiten, Soft Skills, Unternehmensbewusstsein und eine Reihe weiterer Aspekte.

Viele Aussagen sind aber auch jetzt schon veraltet – zum Beispiel: »Es ist Aufgabe der Softwarearchitektur, grundlegende strukturelle Entscheidungen zu treffen, deren spätere Änderung sehr kostspielig wären.« Mittlerweile gibt es moderne architektonische Stile, zum Beispiel Microservices, die die Idee der Inkrementierung bereits enthalten. Strukturelle Änderungen in Microservices sind nicht länger teuer. Natürlich hat eine solche Möglichkeit auch Nachteile, zum Beispiel bei der Kopplung. Viele Bücher über Softwarearchitektur behandeln das als statisches Problem. Ist es einmal gelöst, kann man es sicher ignorieren. In diesem Buch vertreten wir dagegen die Meinung, dass Softwarearchitektur grundsätzlich etwas Dynamisches ist – inklusive ihrer Definition.

Darüber hinaus hat ein Großteil der Materialien über Softwarearchitektur nur noch historische Bedeutung. Leser der Wikipediaseite werden die verwirrendende Ansammlung von Akronymen und Querverweisen zu einem ganzen Wissensuniversum bemerkt haben. Allerdings stehen viele dieser Akronyme für veraltete oder fehlgeschlagene Versuche. Selbst Lösungen, die vor einigen Jahren noch absolut gültig waren, können heute nicht mehr funktionieren, weil sich der Kontext verändert hat. Die Geschichte der Softwarearchitektur ist voll von gescheiterten Versuchen von Softwarearchitekten, die abgebrochen wurden, nachdem die schlechten Nebenwirkungen sichtbar wurden. Viele dieser Lehren werden wir in diesem Buch behandeln.

Warum haben wir ausgerechnet jetzt ein Buch über Grundlagen der Softwarearchitektur geschrieben? Die Softwarearchitektur ist schließlich nicht der einzige Bereich der Softwareentwicklung, der andauernden Änderungen unterworfen ist. Ständig gibt es neue Technologien, Techniken, Fähigkeiten … Es ist tatsächlich leichter, die Dinge aufzulisten, die sich in den letzten zehn Jahren nicht verändert haben. Innerhalb dieses hochdynamischen Ökosystems müssen Softwarearchitekten in der Lage sein, Entscheidungen zu treffen. Da alles – inklusive der Grundlagen, auf deren Basis wir Entscheidungen treffen – ständig in Bewegung ist, sollten Architekten die grundlegenden Axiome früherer Publikationen immer wieder überprüfen und infrage stellen. DevOps spielten in früheren Büchern über Softwarearchitektur keine Rolle, weil es sie beim Schreiben dieser Bücher einfach noch nicht gab.

Beim Studium der Softwarearchitektur sollten die Leser sich darüber klar sein, dass sie – wie die Kunst – nur im richtigen Kontext verstanden werden kann. Viele der Entscheidungen von Softwarearchitekten wurden auf Basis der Realitäten getroffen, in denen sie sich gerade befanden. Eines der Hauptziele der Architektur des ausgehenden 20. Jahrhunderts war beispielsweise eine möglichst kosteneffiziente Nutzung verteilter Ressourcen. Damals war die gesamte Infrastruktur sehr teuer und kommerziell: Betriebssysteme, Application Server, Datenbankserver und so weiter. Stellen Sie sich vor, Sie betreten im Jahr 2002 ein Rechenzentrum und sagen dem Betriebsleiter: »Hey, ich habe eine tolle Idee für einen revolutionären Architekturstil. Dabei läuft jeder Dienst inklusive seiner eigenen Datenbank auf einem eigenen isolierten Rechner (was wir heute als Microservices kennen). Das würde bedeuten, wir bräuchten 50 Windows-Lizenzen, weitere 30 Lizenzen für Application Server und mindestens 50 Lizenzen für Datenbankserver.« Der Versuch, eine Architektur wie Microservices zu schaffen, wäre 2002 unermesslich teuer geworden. Durch das Aufkommen von Open-Source-Lösungen zusammen mit neuen Entwicklungspraktiken wie der DevOps-Revolution sind wir inzwischen jedoch in der Lage, eine Architektur wie die beschriebene zu erstellen. Die Leser sollten daher nicht vergessen, dass alle Architekturen ein Produkt ihres Kontexts sind.

Softwarearchitektur definieren

Die gesamte Branche hat sich bisher damit schwergetan, eine präzise Definition für den Begriff »Softwarearchitektur« zu finden. Einige Architekten verstehen darunter den Bauplan eines Systems, während andere sie als Roadmap für die Entwicklung eines Systems definieren. Das Problem mit diesen verbreiteten Definitionen besteht darin, dass man nicht weiß, was der Bauplan oder die Roadmap tatsächlich enthält. Was genau wird beispielsweise analysiert, wenn ein Architekt eine Architektur analysiert?

Abbildung 1-2 zeigt eine Möglichkeit, sich die Softwarearchitektur vorzustellen. In dieser Definition besteht sie aus der Struktur des Systems (dargestellt durch die dicken schwarzen Linien, die die Architektur stützen), kombiniert mit den architektonischen Eigenschaften (bzw. Fähigkeiten, engl. »-ilities«), die das System unterstützen muss, den architektonischen Entscheidungen und schließlich den Designprinzipien.

Abbildung 1-2: Architektur besteht aus Struktur, den architektonischen Eigenschaften (Fähigkeiten), architektonischen Entscheidungen und Designprinzipien

Die in Abbildung 1-3 gezeigte Struktur des Systems bezieht sich auf den Architekturstil (oder die Stile), in dem das System implementiert ist (zum Beispiel als Microservices, schichtbasiertes Modell oder Microkernel). Die Struktur allein reicht aber nicht, um eine Architektur zu beschreiben. Angenommen, ein Architekt soll eine Architektur beschreiben und seine Antwort lautet: »Es ist eine Microservices-Architektur.« In diesem Fall spricht der Architekt nur von der Struktur des Systems, aber nicht von seiner Architektur. Das Wissen um die architektonischen Eigenschaften, Entscheidungen und Designprinzipien ist genauso wichtig, um die Architektur eines Systems vollständig zu verstehen.

Die architektonischen Eigenschaften bilden eine weitere Dimension in der Definition einer Softwarearchitektur (siehe Abbildung 1-4). Die architektonischen Eigenschaften definieren die Erfolgskriterien eines Systems. Sie stehen üblicherweise senkrecht zur Systemfunktionalität. Beachten Sie, dass für sämtliche aufgelisteten Eigenschaften kein Wissen über die Systemfunktionalität notwendig ist. Dennoch werden sie gebraucht, damit das System korrekt funktioniert. Die architektonischen Eigenschaften sind so wichtig, dass wir ihrer Definition und ihrem Verständnis mehrere Kapitel dieses Buchs gewidmet haben.

Abbildung 1-3: Die Struktur zeigt, welcher Typ des architektonischen Stils im System verwendet wird.

Abbildung 1-4: Architektonische Eigenschaften beziehen sich auf die Fähigkeiten, die das System unterstützen muss.

Der nächste Faktor, der eine Softwarearchitektur definiert, sind die Architekturentscheidungen. Architektonische Entscheidungen definieren die Regeln, nach denen ein System konstruiert wird. So könnte ein Architekt beispielsweise die Entscheidung treffen, dass nur die Business- und Service-Schichten innerhalb einer schichtbasierten Architektur auf die Datenbank zugreifen können (siehe Abbildung 1-5). Damit soll zum Beispiel verhindert werden, dass die Präsentationsschicht direkte Datenbankaufrufe durchführt. Architektonische Entscheidungen definieren die Beschränkungen eines Systems, dienen als Rahmen für die Entwicklungsteams und zeigen ihnen an, welche Dinge erlaubt sind und welche nicht.

Abbildung 1-5: Architektonische Entscheidungen sind Regeln für die Konstruktion eines Systems.

Kann eine architektonische Entscheidung aufgrund bestimmter Bedingungen oder Beschränkungen in einem Systemsteil nicht umgesetzt werden, kann diese Entscheidung (oder Regel) durch die sogenannte Varianz gebrochen werden. In den meisten Unternehmen gibt es Varianzmodelle, die von einem Architektur-Prüfungsgremium (Architecture Review Board, ARB) oder einem Chefarchitekten eingesetzt werden können. Eine Ausnahme für eine bestimmte Architekturentscheidung wird vom ARB (oder dem Chefarchitekten, falls es kein ARB gibt) analysiert und basierend auf den Begründungen und möglichen Vor- und Nachteilen entweder genehmigt oder abgelehnt.

Der letzte Faktor bei der Definition einer Architektur sind die Designprinzipien. Der Unterschied zwischen einem Designprinzip und einer Architekturentscheidung besteht darin, dass ein Designprinzip eher eine Richtlinie als eine strenge und unverrückbare Regel darstellt. Das in Abbildung 1-6 gezeigte Designprinzip besagt beispielsweise, dass die Entwicklungsteams möglichst asynchrones Messaging für die Kommunikation zwischen den Diensten verwenden sollen, um die Performance zu steigern. Eine architektonische Entscheidung (Regel) könnte niemals alle Bedingungen und Optionen für die Kommunikation zwischen den Diensten abdecken. Hier kann ein Designprinzip helfen, um Richtlinien für die bevorzugte Methode (hier das asynchrone Messaging) aufzustellen. Auf diese Weise können Entwickler ggf. ein passenderes Kommunikationsprotokoll (zum Beispiel REST oder gRPC) wählen.

Abbildung 1-6: Designprinzipien sind ...