Eine monolithische Software-Architektur fasst die funktionalen Teile einer Anwendung in einem zusammenhängenden System zusammen. Die Architektur legt fest, wie Komponenten einer Software miteinander in Verbindung stehen und welche Aufgaben sie übernehmen.

Im klassischen Monolithen sind diese Bereiche nicht als unabhängig einsetzbare Teilsysteme organisiert. Änderungen an einem Teil können deshalb Anpassungen, Tests und eine erneute Bereitstellung der gesamten Anwendung erfordern. „Monolithisch“ bedeutet allerdings nicht automatisch ungeordnet: Auch ein Monolith kann intern sauber modularisiert sein.

Programmcode als Darstellung einer zusammenhängenden Software-Anwendung bei IT Wissen
Ein Monolith wird als gemeinsame Anwendung entwickelt und typischerweise als zusammengehörige Einheit bereitgestellt.

Aufbau und Kopplung

Eine monolithische Struktur verzichtet auf die betriebliche Trennung in eigenständig bereitstellbare Dienste. Teile des Systems können eng an bestimmte Hardware, Datenformate oder proprietäre Schnittstellen gebunden sein.

Typische Anwendungen enthalten mindestens zwei funktionale Ebenen:

  • Präsentation: Sie stellt dem Benutzer die interaktive Oberfläche und Funktionen zur Bereitstellung von Informationen zur Verfügung.
  • Anwendungslogik: Sie verarbeitet Regeln, Abläufe und die eigentliche Funktionalität der Applikation.

Häufig kommt eine Datenzugriffsschicht hinzu. In einem Monolithen werden diese Bereiche gemeinsam entwickelt, ausgeführt und ausgeliefert, selbst wenn der Quellcode intern in Module gegliedert ist.

Wichtige Einordnung

Ein Monolith beschreibt vor allem die gemeinsame Bereitstellung. Gute Modulgrenzen, Tests und definierte Schnittstellen können auch innerhalb dieser Architektur Wartbarkeit und Übersicht verbessern.

Mögliche Nachteile

Fehlen klare interne Grenzen, nimmt die Kopplung zwischen den Teilen zu. Mit wachsendem Umfang können daraus mehrere Schwierigkeiten entstehen:

  • Änderungen und Erweiterungen verursachen erhöhten Aufwand, weil Abhängigkeiten gemeinsam geprüft werden müssen.
  • Nebeneffekte werden bei unzureichender Modularisierung schwerer vorhersehbar.
  • Einzelne Funktionen lassen sich nicht ohne Weiteres in anderen Systemen wiederverwenden.
  • Die Anwendung wird als Ganzes skaliert; eine gezielte Lastverteilung nur für besonders beanspruchte Funktionen ist schwieriger.
  • Technologie- oder Plattformwechsel können große Teile des Systems betreffen.

Abgrenzung zu verteilten Architekturen

Einen Gegenentwurf bilden Client-Server-Architekturen und allgemein verteilte Systeme. Dort kommunizieren abgegrenzte Komponenten über definierte Schnittstellen und können teilweise getrennt betrieben werden.

Rich-Clients verlagern beispielsweise Präsentation und Teile der Logik auf einen Client, während zentrale Funktionen über einen Server erreichbar bleiben. Eine serviceorientierte Architektur organisiert Funktionen als logisch abgeschlossene, lose gekoppelte Dienste. Das zugrunde liegende Architekturmuster beschreibt, wie Dienste bereitgestellt, gefunden und genutzt werden.

Beispiel: monolithischer Kernel

Der Begriff kommt auch bei Betriebssystemen vor. Der Kernel des Betriebssystems Linux wird als monolithischer Kernel eingeordnet. Zentrale Grundfunktionen laufen dabei im Kernelraum und stehen in enger Beziehung zu Maschine und Hardware-Ressourcen.

Definierte Schnittstellen schaffen eine Abstraktion dieser Abhängigkeiten. Auf den Grundfunktionen können spezifische Erweiterungen und ladbare Module aufbauen. Dieses Beispiel zeigt, dass „monolithisch“ modulare Erweiterbarkeit nicht grundsätzlich ausschließt.