Architekturstile: Monolith, Module, Microservices

Kaum eine Frage wird in der Softwareentwicklung so leidenschaftlich diskutiert wie die nach dem richtigen Architekturstil. Microservices galten über Jahre als Standard moderner Systeme, Monolithen als veraltet. Inzwischen hat sich das Bild ausgeglichen. Viele Unternehmen haben erfahren, dass Microservices erhebliche Kosten mit sich bringen, und einige bekannte Beispiele haben einzelne Systeme sogar wieder zusammengeführt. Diese Lektion zeigt die drei wichtigsten Stile, ihre Abwägungen und eine Faustregel, mit der Sie für Ihr System eine vernünftige Entscheidung treffen.

1. Drei Stile

Abb. 4.1Monolith, modularer Monolith, Microservices

Ein Monolith ist eine Anwendung, die als Ganzes entwickelt, getestet und ausgeliefert wird, meist mit einer gemeinsamen Datenbank. Das klingt altmodisch, ist aber für die meisten Anwendungen die beste Wahl: Aufrufe zwischen Programmteilen sind schnelle Funktionsaufrufe statt Netzwerkanfragen, Transaktionen über mehrere Tabellen sind einfach, Tests laufen lokal, und es gibt nur eine Sache zu betreiben. Ein modularer Monolith bleibt ein einziges Deployment, trennt aber intern klar: Jedes Modul hat eine eigene Schnittstelle und eigene Tabellen, und andere Module greifen nur über diese Schnittstelle zu. Microservices schließlich sind eigenständige Dienste mit eigener Datenhaltung, die unabhängig ausgeliefert und skaliert werden und über das Netzwerk kommunizieren.

2. Die Abwägungen

Microservices lösen vor allem ein organisatorisches Problem: Wenn viele Teams an einem System arbeiten, blockieren sie sich in einer gemeinsamen Codebasis gegenseitig. Getrennte Dienste mit klaren Verantwortlichkeiten erlauben es jedem Team, unabhängig zu entwickeln und auszuliefern. Dieses Problem haben kleine Teams nicht. Für ein Team von drei bis zehn Personen überwiegen die Kosten von Microservices – mehr Infrastruktur, schwierigere Fehlersuche, verteilte Transaktionen, Versionskonflikte zwischen Diensten – fast immer den Nutzen.

3. Welcher Stil passt?

Probieren Sie den Berater aus. Er bildet die wichtigsten Faktoren ab: Teamgröße, Zahl der klar getrennten Fachbereiche und die Frage, ob einzelne Teile ganz unterschiedliche Last oder Technik brauchen.

4. Grenzen richtig ziehen

Ob Module oder Dienste – entscheidend ist, wo die Grenzen verlaufen. Gute Grenzen folgen fachlichen Bereichen, nicht technischen Schichten. Eine Aufteilung in „Frontend-Service“, „Logik-Service“ und „Datenbank-Service“ erzeugt Abhängigkeiten bei jeder Änderung. Eine Aufteilung nach Bereichen wie „Buchungen“, „Zahlungen“, „Benachrichtigungen“ und „Kundenkonten“ erlaubt es dagegen, einen Bereich zu ändern, ohne die anderen anzufassen. Das Konzept dahinter stammt aus dem Domain-Driven Design und heißt Bounded Context: ein Bereich mit eigener Sprache, eigenen Regeln und eigenen Daten.

Ein gutes Zeichen für eine sinnvolle Grenze ist, dass die meisten Änderungen nur einen Bereich betreffen. Ein schlechtes Zeichen ist, wenn für fast jede neue Funktion mehrere Module oder Dienste gleichzeitig geändert werden müssen, oder wenn Module sich gegenseitig in die Datenbank schauen. Dann ist die Grenze falsch gezogen, und eine Aufteilung in Dienste würde das Problem nur verschlimmern – man spricht dann spöttisch vom „verteilten Monolithen“, der die Nachteile beider Welten vereint.

5. Schrittweise weiterentwickeln

Architektur ist keine einmalige Entscheidung. Die meisten erfolgreichen Systeme sind klein gestartet und schrittweise gewachsen. Ein bewährter Weg sieht so aus: Am Anfang steht ein modularer Monolith mit einer Datenbank, klaren Modulgrenzen und ausgelagerten Hintergrundaufgaben über eine einfache Warteschlange. Wenn einzelne Teile deutlich mehr Last bekommen, werden zuerst Caches, Lesereplikate und mehr Instanzen der Anwendung ergänzt. Erst wenn ein Bereich wirklich eigene Anforderungen hat – etwa eine KI-Verarbeitung mit ganz anderem Ressourcenbedarf oder ein eigenes Team –, wird er als Dienst herausgelöst. Martin Fowler hat dieses Vorgehen als „Monolith First“ beschrieben.

Für die eigene Arbeit bedeutet das: Investieren Sie früh in saubere Module, klare Schnittstellen und gute Tests. Diese Investition zahlt sich in jedem Stil aus und macht spätere Aufteilungen überhaupt erst möglich. Investieren Sie dagegen nicht früh in verteilte Infrastruktur, die Sie noch nicht brauchen. Jede Architekturentscheidung sollte, wie in der ersten Lektion beschrieben, eine Anforderung, eine Entscheidung, ihre Kosten und eine Prüfung benennen. Wie man solche Entscheidungen festhält, zeigt die letzte Lektion des Kurses zu Diagrammen und Architekturentscheidungen. Im nächsten Modul geht es zunächst um die technischen Fundamente, auf denen jede dieser Architekturen aufsetzt: Netzwerke und Nebenläufigkeit.

6. Typische Irrtümer

Einige Irrtümer begegnen bei Architekturentscheidungen immer wieder. Der erste lautet, dass Microservices automatisch besser skalieren. Tatsächlich skaliert ein zustandsloser Monolith hinter einem Load Balancer für die allermeisten Anwendungen hervorragend; der Engpass ist fast immer die Datenbank, und die bleibt auch bei Microservices ein Engpass. Der zweite Irrtum ist, dass ein Monolith zwangsläufig unübersichtlich wird. Unübersichtlich wird Code durch fehlende Struktur, nicht durch ein gemeinsames Deployment; ein modularer Monolith mit klaren Grenzen bleibt über Jahre gut wartbar.

Der dritte Irrtum betrifft die Zukunft: „Wir bauen gleich verteilt, damit wir später nicht umbauen müssen.“ In der Praxis weiß niemand am Anfang genau, wo die Grenzen zwischen Bereichen liegen. Wer zu früh aufteilt, zieht die Grenzen oft falsch – und falsche Grenzen zwischen Diensten sind viel schwerer zu korrigieren als falsche Grenzen zwischen Modulen im selben Code. Ein modularer Monolith lässt sich dagegen mit wachsendem Verständnis nachschärfen und bei Bedarf gezielt aufteilen. Die bessere Absicherung für die Zukunft ist also nicht frühe Verteilung, sondern saubere Struktur.

Zusammengefasst: Wählen Sie den Architekturstil nach Teamgröße, fachlicher Struktur und echten Anforderungen – nicht nach Trends. Für die meisten Unternehmen und Produkte ist ein gut strukturierter modularer Monolith der beste Ausgangspunkt. Er ist schnell entwickelt, einfach betrieben und lässt alle Optionen für später offen. Wenn Sie in einem Vorstellungsgespräch nach Microservices gefragt werden, ist die überzeugendste Antwort oft nicht ein Diagramm mit zwanzig Diensten, sondern eine begründete Erklärung, wann man sie braucht und wann nicht. Diese Fähigkeit, Komplexität bewusst abzulehnen, ist eines der sichersten Kennzeichen erfahrener Architekten. Sie zeigt, dass jemand die Kosten einer Entscheidung ebenso im Blick hat wie ihren Nutzen – und genau darum geht es im System Design von der ersten bis zur letzten Lektion dieses Kurses. Behalten Sie diese Haltung bei jeder Entscheidung im Hinterkopf, und fragen Sie immer: Was gewinnen wir, was bezahlen wir dafür, und woran merken wir, ob es sich gelohnt hat?

Stand: September 2026. Kursmaterial der Klarwerk Akademie. Zahlen zu Latenzen und Kosten sind Größenordnungen zur Orientierung, keine Messwerte.