Sieben Entscheidungskriterien

Monolith, modularer Monolith oder Microservices

0:00 Microservices gelten in vielen Projekten noch immer als Synonym für moderne Architektur. Wer modern sein will, zerlegt. In der Praxis entsteht dabei erstaunlich oft etwas anderes: Dienste, die nur gemeinsam getestet, nur gemeinsam veröffentlicht und nur gemeinsam betrieben werden können. Aus einem schwer wartbaren Monolithen wird dann ein noch schwerer beherrschbarer verteilter Monolith. Gleichzeitig erlebt eine dritte Option ihr Comeback, der modulare Monolith.

0:26 In den nächsten Minuten geht es nicht darum, welcher Stil gerade angesagt ist, sondern um eine Entscheidung für Ihre Anwendung. Sieben Kriterien führen dorthin. Am Ende haben Sie ein Raster, mit dem Sie diese Entscheidung begründen und im Team vertreten können.

Drei Architekturen und der verteilte Monolith

0:42 Bevor wir abwägen, müssen wir wissen, was wir gegeneinander abwägen. Die drei Begriffe fallen in jedem Architekturgespräch, und jeder im Raum meint etwas leicht anderes damit. Dieses erste Kapitel sortiert sie, und zwar nicht nach Technologie, sondern nach der Frage, wie viele Einheiten Sie ausliefern und wer welche Daten verantwortet.

1:02 Dazu kommt das Zerrbild, das man unbedingt erkennen sollte: der verteilte Monolith. Hier kommt bewusst keine Empfehlung für einen Stil. Auch kein „Monolith first" als Faustregel. Stellen Sie sich eine Bauberatung vor: Ob ein Einfamilienhaus, ein Mehrfamilienhaus mit getrennten Wohnungen oder mehrere einzelne Häuser richtig sind, hängt davon ab, wer darin wohnt und was er braucht, nicht davon, was in der Nachbarschaft gerade gebaut wird.

1:28 Genau so arbeitet ein Entscheidungsprofil. Sie nehmen Ihre Anwendung, gehen sieben Kriterien durch und erhalten eine Tendenz. Die kann für die ganze Anwendung gelten oder für einzelne Bereiche unterschiedlich ausfallen. Auch eine Kombination ist ein legitimes Ergebnis. Die entscheidende Spalte ist die mittlere. Monolith und modularer Monolith teilen sich die Deployment-Einheit, sie werden als ein Stück ausgeliefert.

1:52 Was sie trennt, ist das Innere. Beim klassischen Monolithen sind die Grenzen schwach oder rein technisch gezogen, nach Controller, Service und Datenbankzugriff. Beim modularen Monolithen sind sie fachlich, mit definierten Schnittstellen und kontrollierten Abhängigkeiten. Microservices gehen einen Schritt weiter und machen aus jeder fachlichen Grenze auch eine Netzwerk-, Daten- und Deployment-Grenze.

2:15 Das ist der Kern der ganzen Entscheidung: Fachliche Struktur bekommen Sie auch ohne Verteilung. Verteilung ist ein zusätzlicher Schritt, und der muss sich rechnen. Ein verbreiteter Irrtum: Wer Container einsetzt und viele kleine Deployments hat, hat Microservices. Das stimmt nicht. Entscheidend ist, ob sich ein Service ändern lässt, ohne dass andere gleichzeitig angepasst werden müssen.

2:38 Microsoft beschreibt einen Microservice als Umsetzung einer einzelnen Geschäftsfähigkeit innerhalb eines Bounded Context, also eines fachlich abgegrenzten Bereichs mit eigenem Modell, und mit eigener Datenhaltung. DORA, das Forschungsprogramm hinter den bekannten Lieferkennzahlen, wird noch deutlicher. Viele sogenannte serviceorientierte Architekturen erlauben gar nicht, Dienste unabhängig zu testen und zu deployen.

3:01 Dann bleiben genau die Vorteile aus, für die man den Aufwand betrieben hat. Woran erkennt man, dass etwas schiefgelaufen ist? Vier Warnsignale tauchen immer wieder auf. Erstens: Mehrere Dienste gehen nur im Paket in Produktion, weil sie sonst nicht zusammenpassen. Zweitens: Sie teilen sich ein Datenbankschema. Dann reicht eine Spaltenänderung, um drei Teams an einen Tisch zu holen.

3:25 Drittens: lange synchrone Aufrufketten, bei denen ein Dienst den nächsten fragt, und fällt einer aus, fallen alle. Und viertens: Jede fachliche Änderung wandert durch mehrere Dienste und endet in einer zentralen Testumgebung, auf die alle warten. Wer zwei dieser Signale kennt, sollte vor dem nächsten Service innehalten. Der verteilte Monolith ist deshalb so teuer, weil er das Schlechteste aus zwei Welten verbindet: den Betriebsaufwand verteilter Systeme und die Abhängigkeiten eines schlecht strukturierten Monolithen.

3:57 Daraus folgt die Leitfrage, die über allen sieben Kriterien steht. Jede zusätzliche Deployment-Einheit kostet dauerhaft, nämlich eine Pipeline, Überwachung, Sicherheitsupdates und Abstimmung. Welchen messbaren Vorteil bringt genau diese Einheit, und ist er größer als ihre Kosten? Die sieben Kriterien zerlegen diese große Frage in handliche Teile: Domäne, Änderung, Teams, Last, Daten, Betrieb und Kosten. Fangen wir mit den ersten dreien an.

Domäne, Änderungsdynamik und Teamstruktur

4:24 Die ersten drei Kriterien haben eines gemeinsam: Sie fragen nicht nach Technik, sondern nach Struktur. Wo verlaufen die fachlichen Grenzen? Welche Teile müssen sich wirklich unabhängig bewegen? Und wer soll das alles verantworten? Wer diese drei Fragen ehrlich beantwortet, hat die Entscheidung oft schon zur Hälfte getroffen, bevor überhaupt über Skalierung gesprochen wird.

4:46 Microservices brauchen belastbare fachliche Grenzen. Sind Geschäftsregeln, Zuständigkeiten und Begriffe noch im Fluss, werden Servicegrenzen zu früh festgezurrt. Microsoft rät, Dienste entlang von Geschäftsfähigkeiten zu schneiden und nicht nach technischen Schichten wie Datenzugriff oder Messaging. Woran erkennt man eine Grenze?

5:06 Daran, dass dort andere Begriffe gelten, andere Regeln und dass Funktionen sich gemeinsam ändern. Wichtig ist der Hinweis, den Microsoft selbst gibt: Die Bestimmung dieser Grenzen ist ein iterativer, fortlaufender Prozess. Wer das ernst nimmt, sollte Grenzen so ziehen, dass sie sich noch verschieben lassen. Und genau da kommt der modulare Monolith ins Spiel.

5:28 Die Kette zeigt, warum der Zuschnitt am Ende steht und nicht am Anfang. Zuerst wird die Domäne verstanden, gemeinsam mit den Fachleuten, gern am Whiteboard oder mit Event Storming. Daraus ergeben sich Bounded Contexts, also die Bereiche, in denen ein Modell und eine Sprache gelten. Innerhalb jedes Kontexts entsteht dann das Modell im Detail.

5:48 Erst ganz rechts fällt die Entscheidung, ob daraus Module oder Services werden. Der häufigste Fehler ist, diese Reihenfolge umzudrehen und mit der Frage zu beginnen, wie viele Dienste man bauen möchte. Dann richtet sich die Fachlichkeit nach der Technik, und nicht umgekehrt. Der große Vorteil des modularen Monolithen: Fachliche Grenzen lassen sich erproben, bevor sie zu Netzwerk- und Datengrenzen werden.

6:12 Ein falsch gezogenes Modul verschieben Sie im selben Repository, mit einem Refactoring. Ein falsch gezogener Service bedeutet Datenmigration, neue Schnittstellen und Abstimmung zwischen Teams. Nehmen wir Pfotenplan, eine Praxisplattform für einen Verbund von Tierarztpraxen. Termine, Patientenakte, Medikamentenlager und Abrechnung sind dort eigene Module mit eigenen Schnittstellen, aber eine gemeinsame Anwendung.

6:36 Erst wenn sich diese Grenzen über Monate bewährt haben, lohnt die Frage, ob eines davon ein eigener Service werden sollte. Vorher wäre es eine Wette. Nicht jede fachliche Trennung rechtfertigt eine eigene Deployment-Einheit. Interessant wird sie, wenn ein Bereich deutlich schneller oder langsamer geändert wird als der Rest, einen eigenen Release-Takt braucht, eigene Verfügbarkeitsanforderungen hat, separat skaliert werden muss oder eine andere Technologie verlangt.

7:03 Die Gegenprobe ist ernüchternd einfach: Wenn fast jede Änderung mehrere Bereiche gleichzeitig betrifft und die Releases ohnehin abgestimmt werden, schafft eine Aufteilung keine Unabhängigkeit. Sie verteilt nur die Abhängigkeiten über das Netzwerk. Deshalb lautet die Leitfrage nicht, ob ein Bereich unabhängig sein könnte, sondern wie oft er es tatsächlich sein muss.

7:23 Unabhängigkeit ist kein Gefühl, sie lässt sich messen. DORA schlägt dafür Kennzahlen in vier Bereichen vor, und das Prinzip dahinter ist wichtiger als jede einzelne Zeile. Es geht immer um die Frage, wie oft ein Team auf andere warten muss. Wie viele Deployments brauchen Abstimmung? Wie viele Stunden pro Woche gehen in teamübergreifende Gespräche?

7:44 Kann ein Dienst getestet werden, ohne dass eine integrierte Umgebung steht? Und wie oft zwingt eine Änderung woanders zu ungeplanter Nacharbeit? Der praktische Rat: Erheben Sie diese Werte, bevor Sie zerlegen. Nur dann können Sie hinterher zeigen, ob sich die Aufteilung gelohnt hat. Servicegrenzen sind Verantwortungsgrenzen.

8:04 Ein Microservice entfaltet seinen Nutzen dann, wenn ein Team ihn vollständig trägt, von der Entwicklung über Test und Deployment bis zum Betrieb und zur Rufbereitschaft. Arbeiten dagegen mehrere Teams am selben Dienst, steigt der Abstimmungsbedarf. Team Topologies bringt dafür einen hilfreichen Begriff mit: die kognitive Belastung eines Teams.

8:24 Wer zu viele unverbundene Kontexte gleichzeitig verantworten muss, wird langsam. Ein einzelnes Team mit einer überschaubaren Anwendung braucht deshalb selten viele Microservices. Die ehrliche Frage lautet: Gibt es für jeden geplanten Dienst ein Team, das ihn wirklich besitzen kann?

Skalierung, Datenkonsistenz und Betriebsreife

8:41 Jetzt wird es technischer. Die Kriterien vier bis sechs sind die, die in Architekturdiskussionen meist zuerst genannt werden: Last, Daten, Betrieb. Sie sind wichtig, aber sie sind auch die, bei denen am häufigsten mit Erwartungen statt mit Messwerten argumentiert wird. Genau darauf schauen wir in diesem Kapitel. Es gibt gute Gründe, einen Bereich getrennt zu betreiben: stark schwankende Last, rechenintensive Verarbeitung, besonders hohe Verfügbarkeit, getrennte Sicherheitszonen oder regulatorische Vorgaben.

9:12 Bei Pfotenplan sieht das ganz konkret aus. Montags früh, wenn die Wochenendnotfälle nachkontrolliert werden müssen, schnellt die Terminbuchung nach oben, während die Patientenakte gleichmäßig weiterläuft. Das wäre ein Kandidat für eigene Skalierung. Aber die entscheidende Frage ist: Ist dieser Bedarf nachgewiesen, mit echten Messwerten, oder ist er nur eine Möglichkeit, die man sich für später offenhalten möchte?

9:35 Für das Zweite reicht oft ein gut geschnittenes Modul. Hier lauert ein verbreitetes Missverständnis: Ein eigener Dienst sei automatisch isoliert. Das Gegenteil kann der Fall sein. Ruft Dienst A synchron Dienst B auf, und B wartet auf C, dann wandert jede Verzögerung und jeder Ausfall durch die ganze Kette. Isolation muss gebaut werden.

9:56 Dazu gehören Timeouts und Wiederholungen, Circuit Breaker, die einen kranken Dienst vorübergehend abklemmen, und Bulkheads, also Schotten wie im Schiffsrumpf, die ein Leck auf eine Kammer begrenzen. Hinzu kommen idempotente Verarbeitung und, wo es geht, asynchrone Kommunikation. Fehlt das, fällt bei einem Ausfall trotzdem alles aus, nur schwerer nachvollziehbar.

10:18 Bei den Daten zeigt sich der Unterschied am deutlichsten. Ein Monolith kann mehrere Module in einer einzigen lokalen Transaktion zusammenfassen: entweder alles gelingt oder nichts. Bei Microservices hält jeder Dienst seine Daten privat. Microsoft formuliert das klar: Zwei Dienste sollten sich keinen Datenspeicher teilen.

10:37 Das schützt vor versteckter Kopplung, hat aber einen Preis. Eine Änderung über mehrere Dienste wird zu einem Ablauf mit Ereignissen, Ausgleichsschritten im Fehlerfall und zeitversetzter Konsistenz. Microsoft rät deshalb, für jeden fachlichen Vorgang einzeln festzulegen, wo starke Konsistenz nötig ist und wo es genügt, wenn die Daten etwas später übereinstimmen.

10:58 Die Tabelle zeigt, wie diese Abwägung aussieht. Wird ein Medikament abgegeben, muss der Lagerbestand im selben Moment sinken, sonst gibt die nächste Praxis ein Präparat aus, das gar nicht mehr da ist. Das gehört in eine gemeinsame Transaktion. Die Terminbestätigung dagegen darf ein paar Sekunden später kommen, und die Impferinnerung erst recht.

11:18 Das Prinzip dahinter: Je mehr Vorgänge streng konsistent über Bereichsgrenzen hinweg laufen müssen, desto stärker spricht das für einen modularen Monolithen. Je mehr zeitversetzt funktionieren darf, desto realistischer werden getrennte Dienste. Wer diese Tabelle für die eigene Anwendung ausfüllt, sieht die Grenzen oft schon von selbst.

11:38 Jeder neue Dienst bringt seine eigene Infrastruktur mit: eine Pipeline, eine Laufzeitumgebung, Konfiguration, Zugangsdaten und Sicherheitsupdates. Dazu kommt die Beobachtbarkeit. OpenTelemetry beschreibt verteiltes Tracing als Weg, eine einzelne Anfrage über mehrere Dienste hinweg zu verfolgen. Ohne das wird die Ursachensuche in verteilten Systemen zur Detektivarbeit.

12:00 Und schließlich braucht es Zielwerte für die Verfügbarkeit, Alarmierung, Vertragstests zwischen den Diensten und eine klare Zuständigkeit, wenn nachts etwas klemmt. Ein modularer Monolith braucht ebenfalls professionellen Betrieb, aber eben für eine Einheit statt für zehn. Die Leitfrage: Kann Ihre Plattform das heute schon leisten?

Gesamtkosten, Matrix und evolutionärer Pfad

12:20 Das letzte Kriterium führt alles zusammen: die Kosten. Danach verdichten wir die sieben Antworten zu einer Matrix, schauen uns an, wie ein modularer Monolith seine Grenzen technisch absichert, und wie eine bestehende Anwendung Schritt für Schritt wachsen kann, ohne großen Knall. Zum Schluss die Frage, was KI dabei leisten kann und wo sie aufhören muss.

12:40 Die Gegenüberstellung macht sichtbar, warum diese Rechnung so oft schiefgeht. Links stehen Kosten, die dauerhaft anfallen und gern unterschätzt werden: Pipelines, Plattformbetrieb, Überwachung, Sicherheit, Vertragstests, Abstimmung zwischen Teams und die Mühe mit verteilten Daten. Rechts stehen Vorteile, die möglich sind, aber nicht garantiert: schnellere unabhängige Releases, gezielte Skalierung, Fehlerisolation, klarere Verantwortung.

13:05 Der Knackpunkt ist die Asymmetrie. Die linke Seite bezahlen Sie in jedem Fall, ab dem ersten Tag. Die rechte bekommen Sie nur, wenn die Kriterien eins bis sechs erfüllt sind. Ein modularer Monolith ist deshalb oft dann wirtschaftlich, wenn fachliche Ordnung gebraucht wird, getrennte Deployments aber keinen Mehrwert bringen.

13:25 Diese Matrix fasst zusammen, was die sieben Kriterien in typischen Lagen meist ergeben. Lesen Sie sie als Tendenz, nicht als Regelwerk. Auffällig ist, wie oft der modulare Monolith auftaucht: bei einem Team, bei unklaren Grenzen, bei komplexer Domäne mit gemeinsamen Transaktionen. Microservices erscheinen dort, wo mehrere autonome Teams eigene Wertströme verantworten oder einzelne Bereiche eigene Skalierung und eigene Zielwerte brauchen.

13:50 Und zwei Zeilen sind echte Warnungen: Geteilte Tabellen mit gemeinsamen Releases bedeuten verteilter Monolith. Fehlende Automatisierung und Beobachtbarkeit bedeuten, dass zuerst modularisiert und der Betrieb verbessert werden sollte, bevor irgendetwas verteilt wird. Ein wichtiger Gedanke zum Mitnehmen: Der modulare Monolith ist kein Zwischenstopp und kein gescheiterter Microservice-Entwurf. Er kann die dauerhafte Zielarchitektur sein.

14:16 Damit er das trägt, braucht er Disziplin. Jedes Modul hat eine öffentliche Schnittstelle und verbirgt seine Implementierung. Abhängigkeiten zeigen in eine Richtung, Zyklen gibt es nicht. Module werden einzeln getestet, fachliche Ereignisse sind dokumentiert. Und vor allem: Die Grenzen stehen nicht nur auf einem Diagramm im Wiki, sondern werden bei jedem Build automatisch geprüft.

14:39 Sonst verwischen sie, Commit für Commit, und nach zwei Jahren ist aus dem modularen wieder ein gewöhnlicher Monolith geworden. So sieht diese automatische Prüfung in einer Java-Anwendung aus. Zwei Werkzeuge, ein Gedanke. Spring Modulith liest die Paketstruktur der Anwendung, erkennt daraus die Module und prüft mit einem einzigen Aufruf, ob es Zyklen gibt oder ob ein Modul in die internen Pakete eines anderen greift.

15:04 ArchUnit formuliert Architekturregeln als ganz normale Tests, hier die Regel, dass zwischen den fachlichen Bereichen keine Zyklen entstehen dürfen. Worauf es ankommt: Beides läuft im Build. Verletzt jemand eine Grenze, wird die Pipeline rot, bevor der Fehler im Hauptzweig landet. Die Architektur wird damit überprüfbar, statt nur beschrieben.

15:25 Bei einer bestehenden Anwendung lautet die realistische Entscheidung selten: alles ersetzen. Der tragfähige Weg beginnt mit Sichtbarkeit, also mit der Frage, welche Fähigkeiten es gibt, was sich gemeinsam ändert und welche Daten geteilt werden. Dann werden Modulgrenzen gezogen und technisch abgesichert, Module isoliert getestet und die Datenverantwortung geklärt.

15:45 Erst danach kommen Messwerte ins Spiel, die echte Engpässe zeigen. Und nur dort, wo sich ein Modul bewährt hat und ein konkreter Grund vorliegt, wird es herausgelöst. Das Strangler-Fig-Muster beschreibt genau das: Ein Proxy leitet Anfragen Stück für Stück auf den neuen Dienst um, während der Rest weiterläuft. KI-Assistenten und Coding-Agenten können in der Architekturarbeit viel Fleißarbeit abnehmen: Abhängigkeiten analysieren, Zyklen finden, erste Diagramme zeichnen, Modulprüfungen und Entwürfe für Entscheidungsdokumente vorschlagen.

16:17 Aber eine Grenze bleibt. Aus Quellcode allein erkennt keine KI, welche fachlichen Grenzen, Verantwortlichkeiten und Konsistenzanforderungen gelten. Eine Gruppe von Klassen, die technisch zusammenhängt, ist noch lange kein Bounded Context. Deshalb sind KI-Vorschläge Hypothesen. Und ein Agent, der selbstständig aus einem Monolithen Microservices erzeugt und in Produktion bringt, ist kein Fortschritt, sondern ein Risiko.

16:41 Die Entscheidung hält ein Architecture Decision Record fest, verantwortet und freigegeben von Menschen.

Übung

16:48 Genug Theorie. Jetzt kommen die sieben Kriterien auf eine echte Anwendung, am besten auf Ihre eigene. Das Ziel ist keine perfekte Zielarchitektur, sondern eine Entscheidung, die Sie begründen können, und ein erster Schritt, mit dem Sie morgen anfangen. Als Übungsfall dient wieder Pfotenplan. Die Plattform bündelt Terminbuchung, Patientenakte, Medikamentenlager, Abrechnung und Erinnerungsversand für einen Verbund von Tierarztpraxen.

17:14 Bisher entwickelt ein einziges Team alles als eine Anwendung. Jetzt soll ein zweites Team die Terminbuchung übernehmen. Das ist genau die Lage, in der die Frage nach Microservices typischerweise auf den Tisch kommt: Ein neues Team, ein Bereich mit eigener Lastspitze, und der Wunsch, unabhängiger zu werden. Ob daraus ein eigener Dienst folgt oder ein sauber abgegrenztes Modul, ist offen. Genau das sollen die sieben Kriterien klären.

17:40 Der Ablauf führt vom Groben ins Konkrete. Zuerst die fachlichen Bereiche benennen und markieren, wo sie sich Daten teilen. Dann jedes Kriterium einzeln durchgehen und notieren, was für eine Modulgrenze und was für eine Servicegrenze spricht. Ein besonders wichtiger Zwischenschritt ist die Liste der Vorgänge, die streng konsistent über Bereichsgrenzen hinweg laufen müssen.

18:02 Sie zeigt oft schneller als jede Diskussion, wo eine Trennung weh tut. Aus all dem ergibt sich eine Tendenz, für die Gesamtarchitektur und für jeden Bereich. Und am Ende steht das Ganze als Entscheidungsdokument mit Kontext, Entscheidung und Konsequenzen. Worum es bei dieser Aufgabe geht, ist nicht das richtige Kästchen in der Matrix.

18:21 Es geht um die Fähigkeit, eine Architekturentscheidung entlang nachvollziehbarer Kriterien zu begründen und sie gegen die beiden anderen Stile abzugrenzen. Fertig sind Sie, wenn ein Entwurf vorliegt, der für jedes der sieben Kriterien eine Antwort enthält, die gewählte Architektur samt ihren Konsequenzen benennt und den ersten konkreten Schritt auf dem Weg dorthin festhält.

18:41 Ein Tipp: Schreiben Sie die Konsequenzen ehrlich auf, auch die unangenehmen. Genau dieser Teil macht ein solches Dokument später wertvoll, wenn jemand fragt, warum damals so entschieden wurde.

Und jetzt?

18:52 Was bleibt? Die Frage Monolith oder Microservices hat keine allgemeine Antwort, aber sie hat eine begründbare Antwort für Ihre Anwendung, und manchmal fällt sie für jeden Bereich anders aus. Die sieben Kriterien helfen, diese Antwort zu finden, bevor teure Grenzen gezogen werden. Wenn Sie jetzt tiefer einsteigen wollen, in Architekturstile, Systemzuschnitt, Schnittstellen, Datenarchitektur und Betrieb, dann ist das Seminar Architektur und Technologien für moderne Web-Anwendungen der nächste Schritt.

19:21 Es lohnt sich besonders, wenn fachliche Grenzen, Betriebsreife oder der Modernisierungspfad bei Ihnen noch offen sind. Alles Weitere finden Sie auf learning-master.de.