Grundlagen der Softwarearchitektur

Der Bauplan für das große Ganze

Softwarearchitektur bildet das fundamentale Gerüst eines jeden Softwaresystems. Ähnlich wie bei der Architektur eines Gebäudes, wo vor dem Innenausbau festgelegt werden muss, wo tragende Wände stehen und wie Versorgungsleitungen verlaufen, definiert die Softwarearchitektur die grundlegende Organisation der Software. Sie ist die Ebene der strategischen Entscheidungen, die später nur schwierig und mit hohen Kosten zu ändern sind. Eine Softwarearchitektur manifestiert sich in drei wesentlichen Aspekten:

1. Komponenten: Die großen Bausteine des Systems (z. B. Datenbank, Webserver, Abrechnungsmodul).
2. Beziehungen: Die Art und Weise, wie diese Bausteine miteinander kommunizieren und interagieren (z. B. über REST-APIs, direkte Funktionsaufrufe oder Nachrichtenschlangen).
3. Prinzipien: Die Regeln und Leitlinien, die den Entwurf und die zukünftige Weiterentwicklung des Systems steuern.

Architektur vs. Design: Strategie trifft Taktik

Obwohl die Begriffe oft synonym verwendet werden, unterscheiden sie sich in ihrer Flughöhe und Tragweite. Eine hilfreiche Analogie ist der Unterschied zwischen Strategie und Taktik:

• Softwarearchitektur (Strategie): Hier werden systemweite Entscheidungen getroffen. Es geht um die Struktur des Gesamtsystems und die Kommunikation zwischen den großen Blöcken. Ein Beispiel wäre die Entscheidung für eine Microservices-Architektur, um einzelne Geschäftsbereiche unabhängig voneinander skalieren zu können.
• Softwareentwurf / Design (Taktik): Dies betrifft die interne Struktur einzelner Komponenten. Es sind Detailentscheidungen, die sich auf Klassen, Funktionen und Algorithmen beziehen und leichter revidierbar sind. Hier kommen die dir bereits bekannten Design Patterns (wie Singleton oder Factory) und Clean Code Prinzipien zum Einsatz. Während die Architektur festlegt, dass es ein Abrechnungsmodul gibt, bestimmt das Design, wie die Klassen innerhalb dieses Moduls organisiert sind.

Einfluss auf Qualitätsmerkmale

Die Architektur hat direkten Einfluss auf die sogenannten nicht-funktionalen Anforderungen eines Systems. Während der Code bestimmt, was das System tut (Funktionalität), bestimmt die Architektur, wie gut es das tut (Qualität). Eine schlechte Architektur führt oft zum sogenannten "Big Ball of Mud" – einem unwartbaren Chaos, das Projekte scheitern lässt.

• Wartbarkeit: Eine saubere Trennung von Zuständigkeiten verhindert, dass Änderungen an einer Stelle das gesamte System zum Einsturz bringen. Fehler lassen sich schneller lokalisieren und neue Features sicher einbauen.
• Skalierbarkeit: Wenn die Zahl der Nutzenden steigt, muss das System wachsen. Die Architektur entscheidet, ob man einfach mehr Hardware hinzufügen kann (z. B. weitere Server in einer Cloud-Umgebung) oder ob das System unter Last zusammenbricht.
• Performance: Entscheidungen über Datenhaltung und Kommunikationswege (z. B. synchron vs. asynchron) bestimmen maßgeblich die Antwortzeiten und den Durchsatz des Systems.
• Sicherheit: Sicherheitskonzepte wie "Security by Design" müssen tief in der Architektur verankert sein, etwa durch die strikte Isolierung sensibler Datenbereiche von öffentlichen Schnittstellen.

Moderne Architekturmuster im Überblick

Du kennst bereits die Schichtenarchitektur (horizontale Teilung, z. B. Präsentation, Logik, Daten) und das Client-Server-Modell. Für komplexe, hochskalierbare Anforderungen haben sich weitere Muster etabliert:

• Microservices: Im Gegensatz zum monolithischen Ansatz der Schichtenarchitektur wird das System hier in viele kleine, unabhängige Dienste zerlegt. Jeder Service erfüllt genau eine fachliche Aufgabe (z. B. "Warenkorb verwalten" oder "Rechnung erstellen") und läuft als eigener Prozess.
  • Beispiel: Ein Online-Shop besteht aus einem Service für den Produktkatalog, einem für den Warenkorb und einem für Empfehlungen. Fällt der Empfehlungs-Service aus, können Kund:innen trotzdem noch einkaufen.
  • Vorteil: Teams können unabhängig voneinander arbeiten, Technologien pro Service frei wählen und einzelne Teile des Systems gezielt skalieren.
• Event-Driven Architecture (Ereignisgesteuerte Architektur): In diesem Muster kommunizieren Komponenten nicht durch direkte Aufrufe, sondern asynchron über Ereignisse (Events). Eine Komponente sendet ein Signal "Bestellung eingegangen", und andere Komponenten reagieren darauf, ohne dass der Sender wissen muss, wer zuhört.
  • Beispiel: Wenn du dich auf einer Website registrierst, wird das Event "UserRegistered" ausgelöst. Daraufhin sendet ein Modul eine Willkommens-Mail, ein anderes legt einen Eintrag im CRM an und ein drittes erstellt einen Gutschein. All das passiert parallel und entkoppelt.
  • Vorteil: Extrem hohe Entkopplung und Reaktionsfähigkeit, ideal für Echtzeitsysteme.