Bekannte Architekturmuster
Architekturmuster sind bewährte Lösungen für wiederkehrende Strukturprobleme. Die meisten realen Systeme kombinieren mehrere davon.
Die Microservices-Architektur ist dabei kein Qualitätsmerkmal an sich. Für viele mittelständische Vorhaben ist ein modularer Monolith die bessere Wahl, weil er die fachliche Trennung bietet, ohne den Betriebsaufwand verteilter Systeme. Wo fachliche Grenzen verlaufen, klärt Domain-driven Design mit dem Konzept des Bounded Context. Die hexagonale Architektur geht auf Alistair Cockburn zurück; verwandte Ansätze sind die Onion Architecture und die Clean Architecture.
Softwarearchitektur vs. Systemarchitektur
Die Begriffe überschneiden sich, haben aber einen unterschiedlichen Zuschnitt. Die Systemarchitektur betrachtet das Gesamtsystem: Software, Hardware, Netzwerke, Infrastruktur und die Verbindungen zu anderen Systemen. Die Softwarearchitektur betrachtet die innere Struktur der Software selbst. Daneben stehen das feinere Softwaredesign und die übergreifende Unternehmensarchitektur.
In der Praxis hängen die Ebenen eng zusammen: Ob ein Dienst in der Cloud getrennt skalieren kann, ist eine Frage der Systemarchitektur, setzt aber eine Softwarearchitektur voraus, die diesen Dienst überhaupt abtrennt. Wie wir beide Ebenen gemeinsam planen, beschreibt unsere Leistung Systemarchitektur und Design.
Ein Händler will ein Kundenportal bauen, in dem Geschäftskunden mit eigenen Preisen bestellen. Preise, Bestände und Kundenkonten liegen im ERP, Produktdaten im PIM. Eine mögliche Softwarearchitektur:
- Modularer Monolith als Kern: Module für Katalog, Preise, Warenkorb, Bestellungen und Kundenkonten mit klaren internen Schnittstellen. Ein Team kann alles in einer Codebasis weiterentwickeln.
- Hexagonaler Zuschnitt der Fachlogik: Die Preislogik kennt das ERP nicht direkt, sondern nur einen „Preis-Port“. Ein Adapter übersetzt auf die ERP-Schnittstelle. Wird das ERP später ersetzt, bleibt die Fachlogik unverändert.
- Ereignisse für die Integration: Eine bestätigte Bestellung erzeugt das Ereignis „Bestellung angelegt“. ERP-Export, Bestätigungs-E-Mail und Statistik reagieren unabhängig darauf. Fällt das ERP kurz aus, gehen keine Bestellungen verloren, weil die Ereignisse in einer Warteschlange liegen.
- Gezielte Abtrennung: Nur die Produktsuche, die deutlich mehr Last trägt als der Rest, läuft als eigener Dienst. Alles andere bleibt im Monolithen.
Das Beispiel zeigt die Grundregel: Muster werden nach Anforderungen gewählt, nicht nach Mode. Eine reine Microservice-Landschaft hätte hier mehr Betriebsaufwand erzeugt, ohne ein konkretes Problem zu lösen.
Architektur dokumentieren und entscheiden
ISO/IEC/IEEE 42010 beschreibt, wie eine Architekturbeschreibung aufgebaut ist: Sie richtet sich an Stakeholder mit bestimmten Anliegen (Concerns) und zeigt das System in verschiedenen Sichten. Verbreitete Hilfsmittel in der Praxis:
- arc42: eine Gliederungsvorlage für Architekturdokumentation von Gernot Starke und Peter Hruschka, im deutschsprachigen Raum weit verbreitet.
- C4-Modell: vier Zoomstufen von Kontext über Container und Komponenten bis zum Code, entwickelt von Simon Brown.
- Architecture Decision Records (ADR): kurze Notizen je Entscheidung mit Kontext, Entscheidung und Konsequenzen. Sie beantworten Jahre später die Frage, warum etwas so gebaut wurde.
Architektur ist außerdem nie fertig. Systeme wachsen, Anforderungen ändern sich, und ohne Pflege erodiert die Struktur. Regelmäßiges Refactoring hält sie gesund. Ist die Struktur bereits verloren, wird aus dem System schnell Legacy-Software, deren Modernisierung deutlich mehr kostet als laufende Pflege. Das Gesetz von Conway (Melvin Conway, 1968) erinnert zudem daran, dass Systeme die Kommunikationsstrukturen der Organisation abbilden, die sie baut. Architektur und Teamzuschnitt gehören deshalb zusammen.
FAQ zur Softwarearchitektur
Was versteht man unter Softwarearchitektur?
Softwarearchitektur ist die grundlegende Struktur eines Softwaresystems: seine Bausteine, deren Beziehungen und die Prinzipien, nach denen es entworfen und weiterentwickelt wird. Sie umfasst vor allem die Entscheidungen, die sich später nur schwer ändern lassen.
Welche Architekturmuster gibt es?
Verbreitet sind die Schichtenarchitektur, der modulare Monolith, Microservices, die ereignisgesteuerte Architektur, die hexagonale Architektur (Ports and Adapters), Client-Server und Pipes and Filters. Reale Systeme kombinieren meist mehrere Muster.
Was ist der Unterschied zwischen Softwarearchitektur und Systemarchitektur?
Die Systemarchitektur beschreibt ein Gesamtsystem aus Software, Hardware, Netzwerk und Betrieb sowie seine Verbindungen zu anderen Systemen. Die Softwarearchitektur beschreibt die innere Struktur der Software selbst, also Module, Schnittstellen und die Verteilung der Fachlogik.
Was macht ein Softwarearchitekt?
Ein Softwarearchitekt leitet aus Anforderungen die Struktur eines Systems ab, wägt Alternativen ab, dokumentiert Entscheidungen und achtet darauf, dass die Umsetzung die Struktur nicht unterläuft. In kleineren Teams übernehmen erfahrene Entwickler diese Rolle mit.
Wann sollte man über die Architektur entscheiden?
Die grundlegenden Entscheidungen, etwa Monolith oder verteilte Dienste, Datenhaltung und Integrationsweg, gehören an den Anfang, sobald die wichtigsten Qualitätsanforderungen bekannt sind. Details können und sollten später fallen, wenn mehr Wissen vorliegt. Auch in agilen Projekten braucht es diesen Rahmen.
Weiterführend: Welche Architektur sich für Backends und APIs bewährt, zeigt unser Beitrag zu Enterprise-Backend-Architektur und API-Design.
