Grundlagen der Softwarearchitektur

Das Konzept: Komponenten, Beziehungen und Prinzipien

Stell dir vor, du entwickelst ein neues, komplexes ERP-System für ein großes Unternehmen. Bevor du die erste Zeile Code schreibst, musst du festlegen, wie das System im Großen und Ganzen aufgebaut ist. Genau das ist die Softwarearchitektur: Sie definiert die grundlegende Organisation eines Systems.

Diese Organisation manifestiert sich in drei wesentlichen Aspekten:

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

Architektur vs. Entwurf (Design): Strategie trifft Taktik

Die Begriffe Architektur und Design werden oft synonym verwendet, unterscheiden sich aber deutlich in ihrer Tragweite:

• Softwarearchitektur ist die Ebene der strategischen, systemweiten Entscheidungen. Hier legst du fest, dass es ein separates Abrechnungsmodul gibt und wie es mit der Datenbank kommuniziert. Wenn du diese Entscheidungen später ändern musst, treibt das die Total Cost of Ownership (TCO) massiv in die Höhe.
• Softwareentwurf (Design) ist die Ebene der taktischen, komponenteninternen Entscheidungen. Hier bestimmst du, wie der Code innerhalb des Abrechnungsmoduls strukturiert ist. Du entscheidest über konkrete Klassenstrukturen oder Algorithmen.

Ein anschaulicher Vergleich: Die Architektur plant die Stadt und das Straßennetz, das Design plant den Grundriss der einzelnen Häuser.

Der Einfluss auf den Projekterfolg und die Softwarequalität

Du kennst bereits die Qualitätsmerkmale nach ISO/IEC 25010. Die gewählte Softwarearchitektur entscheidet maßgeblich darüber, ob diese Anforderungen in der Praxis erfüllt werden, und minimiert so fundamentale Projektrisiken:

• Wartbarkeit: Eine saubere Trennung von Komponenten verhindert, dass eine kleine Code-Änderung das gesamte System lahmlegt.
• Skalierbarkeit: Die Architektur bestimmt, ob das System bei steigenden Nutzerzahlen einfach durch zusätzliche Hardware (z. B. weitere Server) erweitert werden kann.
• Performance: Architektonische Entscheidungen über Datenhaltung und Kommunikationswege (synchron vs. asynchron) definieren die Antwortzeiten des Systems.
• Sicherheit: Ein Konzept wie "Security by Design" verankert den Schutz sensibler Daten tief in der Architektur, indem beispielsweise öffentliche Schnittstellen strikt von internen Datenbanken isoliert werden.

Klassische Architekturmuster: Schichten und Client-Server

Um bewährte Strukturen nicht jedes Mal neu erfinden zu müssen, nutzt die Entwicklung Architekturmuster (Architectural Patterns). Zwei grundlegende Klassiker sind:

• Schichtenarchitektur (Layered Architecture): Das System wird horizontal in logische Schichten unterteilt (meist Präsentation, Geschäftslogik und Datenhaltung). Jede Schicht darf nur mit der direkt darunterliegenden kommunizieren. Dies eignet sich hervorragend für klassische, monolithische Unternehmensanwendungen.
• Client-Server-Modell: Die Aufgaben werden im Netzwerk verteilt. Ein zentraler Server stellt Ressourcen oder Dienste bereit, während mehrere Clients (z. B. Webbrowser oder mobile Apps) diese Dienste anfragen und konsumieren.

Moderne Architekturmuster: Microservices und Event-Driven

Für hochskalierbare und komplexe Cloud-Anwendungen werden heute oft modernere Muster eingesetzt:

• Microservices: Das System wird in viele kleine, unabhängige Dienste zerlegt, die jeweils genau eine fachliche Aufgabe erfüllen. Beispiel: Ein Online-Shop hat einen Service für den Warenkorb und einen für Produktempfehlungen. Fällt der Empfehlungs-Service aus, können Kund:innen trotzdem weiter einkaufen. Teams können diese Services unabhängig voneinander entwickeln und skalieren.
• Event-Driven Architecture (Ereignisgesteuerte Architektur): Komponenten kommunizieren hier nicht durch direkte Aufrufe, sondern asynchron über Ereignisse (Events). Beispiel: Ein:e Nutzer:in registriert sich. Das System feuert das Event UserRegistered. Ein Mail-Service reagiert darauf und sendet eine Willkommens-Mail, während parallel ein CRM-Service den neuen Kontakt anlegt – völlig entkoppelt voneinander.