SaaS-Monolith zu modularer Architektur: erst restrukturieren, aufteilen nur wenn ein Test es belegt

Dieser Leitfaden richtet sich an SaaS-Gründer, CTOs und Engineering Leads, deren Produkt langsam ausgeliefert wird, weil jede Änderung alles berührt. Er setzt ein produktives System mit zahlenden Mandanten voraus. Den Aufbau einer ersten Version behandelt unsere SaaS-MVP-Architektur-Roadmap, das größere Bild der Leitfaden zum SaaS Platform Engineering und die allgemeine Wahl zwischen Neuentwicklung, Refactoring und Replatforming der Leitfaden zur digitalen Transformation und Modernisierung.

Inhalt dieses Leitfadens

• Ist der Monolith wirklich das Problem?
• Das Ziel: ein modularer Monolith vor jedweden Services
• Den Weg wählen
• Nahtstellen finden, dann Grenzen ziehen
• Schritt für Schritt: ein Modularisierungspfad
• Mandanten, Abrechnung und Daten während des Umbaus
• KI bei einer Modernisierung
• Welcher Liefernachweis existiert und welcher nicht
• Alternativen: Wer führt die Arbeit durch
• Grenzen dieses Leitfadens
• Häufig gestellte Fragen
• Nächster Schritt

Ist der Monolith wirklich das Problem?

Ein Monolith ist eine Anwendung, die als eine Einheit deployed wird. Das ist kein Fehler an sich: Martin Fowlers Empfehlung „Monolith First“ stellt fest, dass fast alle erfolgreichen Microservice-Projekte mit einem Monolithen begannen, der zu groß wurde, und dass stabile Service-Grenzen schwer zu ziehen sind, bevor man die Domäne kennt. Achten Sie auf diese Zeichen, bevor Sie etwas umstrukturieren:

• Änderungen kollidieren. Mehrere Teams bearbeiten dieselben Dateien, Releases warten aufeinander, und eine kleine Korrektur erfordert einen vollständigen Regressionstest.
• Ein Fehler legt alles lahm. Ein aufwändiger Report oder Import verlangsamt Anmeldung und Abrechnung für jeden Mandanten.
• Niemand kann einen Teil erklären. Code greift auf Daten anderer Code-Bereiche zu, sodass eine Änderung in einem Bereich einen anderen zerstört.
• Eine Workload benötigt andere Behandlung. Suche, Medienverarbeitung oder KI-Features brauchen andere Hardware, Skalierung oder Release-Regeln als der Rest.

Restrukturieren Sie nicht für ein Problem, das woanders liegt. Langsame Seiten haben oft fehlende Indizes, instabile Releases oft fehlende Tests, und eine hohe Rechnung hat oft fehlende Kostenzuordnung, die unser Leitfaden zur Cloud-Kostenkontrolle behandelt. Ist das System alt, nicht mehr unterstützt oder insgesamt undurchsichtig, führen Sie zuerst die Legacy-System-Bewertungs-Checkliste durch.

Das Ziel: ein modularer Monolith vor jedweden Services

Ein modularer Monolith ist weiterhin eine einzige deploybare Anwendung, aber sein Code ist in Module unterteilt, jedes mit einer klaren öffentlichen Schnittstelle und eigenen Daten. Shopifys Engineering-Team beschrieb diesen Ansatz für seine große Rails-Anwendung: Komponenten mit definierten Grenzen, sodass Entwickler in den für sie relevanten Bereichen arbeiten und Tests für eine Komponente statt für die gesamte Anwendung laufen können. Derselbe Artikel führt Lektionen auf, die das Team beim erneuten Start anders anwenden würde – planen Sie daher für Iteration.

Was ein Modul real macht, nicht nur zu einem Ordner:

1. Eine öffentliche Schnittstelle. Andere Module rufen Funktionen auf oder senden Events; sie greifen nie auf Interna zu.
2. Eigene Daten. Jedes Modul besitzt seine Tabellen. Kein anderes Modul liest oder joint sie direkt.
3. Ein Eigentümer. Ein Team ist verantwortlich für das Verhalten des Moduls und seine Tests.
4. Eine durchgesetzte Regel. Eine Prüfung im Build schlägt fehl, wenn ein Modul die Interna eines anderen importiert.

Für ein SaaS-Produkt sind typische Module: Identität und Zugriff, Mandanten und Berechtigungen, Abrechnung und Abonnements, die Kern-Produktdomänen, Benachrichtigungen und Reporting. Mandantenkontext durchläuft jedes Modul; der Leitfaden zur Multi-Tenant-Architektur erläutert die Isolationsentscheidungen, auf denen diese Wahl beruht.

Den Weg wählen

Die meisten Produkte enden mit einem modularen Kern und null bis wenigen extrahierten Services. Teams sollten ein vollständiges Microservice-Gebäude als Ziel betrachten, das man sich erarbeiten muss, nicht als Ausgangspunkt.

Nahtstellen finden, dann Grenzen ziehen

Eine Naht ist eine Stelle, an der ein Teil des Codes vom Rest mit wenig Aufwand getrennt werden kann. Finden Sie sie aus Belegen, nicht aus einem Architekturdiagramm:

• Abhängigkeitskarte. Erzeugen Sie den tatsächlichen Import-Graphen. Module mit vielen eingehenden und wenigen ausgehenden Aufrufen sind gute erste Kandidaten; verflochtene Kerne kommen zuletzt.
• Dateneigentümerschaft. Für jede Tabelle: listen Sie auf, welcher Code sie liest und schreibt. Tabellen, die von vielen Bereichen beschrieben werden, zeigen eine Grenze, die noch nicht existiert.
• Änderungshistorie. Dateien, die sich gemeinsam ändern, gehören in der Regel zusammen. Dateien, die sich unabhängig voneinander ändern, deuten auf eine Grenze hin.
• Geschäftssprache. Namen, die an verschiedenen Stellen verschiedenes bedeuten – etwa das Wort „Account“ bei der Abrechnung und beim Anmelden – markieren die Grenzen zwischen Domänen.

Wählen Sie das erste Modul nach niedrigem Risiko und hohem Lerneffekt: eine klare Funktion, eine kleine Schnittstelle und wenig gemeinsame Daten. Benachrichtigungen oder Reporting eignen sich oft. Lassen Sie Abrechnung und Identität, bis die Methode erprobt ist, und behandeln Sie sie dann mit besonderer Sorgfalt, da Fehler dort jeden Mandanten betreffen.

Mandanten, Abrechnung und Daten während des Umbaus

Multi-Tenancy ist der Bereich, in dem Restrukturierung unbemerkt schiefgeht. Drei Regeln helfen:

• Mandantenkontext ist nicht optional. Jedes Modul und jeder neue Service muss den Mandantenbezeichner empfangen und durchsetzen – idealerweise in gemeinsamem Code, nicht manuell wiederholt.
• Mandanten in Kohorten migrieren. Mit internen und wohlgesonnenen Mandanten beginnen, Fehler und Performance beobachten, dann ausweiten. Eine Migration, die für zehn kleine Mandanten funktioniert, muss nicht für einen mit jahrelangen Daten funktionieren.
• Abrechnung und Berechtigungen wie einen Vertrag behandeln. Nutzungsereignisse und Planlimits müssen für Kunden identisch bleiben, während der Code darunter sich ändert. Rechnungen und Berechtigungsergebnisse aus altem und neuem Pfad vergleichen, bevor umgeschaltet wird.

Datenverschiebungen benötigen einen Plan für Lese- und Schreibvorgänge während der Übergangszeit: doppelte Schreibvorgänge, Change Capture oder ein kurzer Freeze – jede Variante mit einer anschließenden Abgleichsprüfung.

Welcher Liefernachweis existiert und welcher nicht

Netbase baut und betreibt Multi-Tenant-SaaS-Produkte, was das Setting ist, für das dieser Leitfaden geschrieben wurde:

• Cloodo Workspace. Ein Work-Management-Digital-Workplace mit CRM-, HRM-, Cloud-ERP- und KI-Modulen in einem Produkt, gebaut und betrieben als Netbase Business Division (Cloodo-Nachweis).
• Cloud ERP für einen US-Kunden (nicht genannt). Ein Multi-Tenant-Cloud-ERP, das Netbase seit 2020 als Offshore-Entwicklungs- und Managing-Partner entwickelt (Cloud-ERP-Nachweis).
• Printcart. Das Web-to-Print-SaaS der Netbase Business Divisions (Printcart-Nachweis).
• Netztech. Ein Shop, der in 35 Arbeitstagen von Magento 1 auf Magento 2 Commerce migriert wurde (Netztech-Nachweis). Es handelt sich um eine Plattformmigration, nicht um eine Monolith-Dekomposition.

Der Lieferlebenszyklus von Netbase umfasst modulare und produktisierte Komponenten, und sein SaaS-Produktbeschleuniger ist aus wiederverwendbaren Modulen aufgebaut.

Was nicht existiert. Kein veröffentlichter Netbase-Nachweis beschreibt die Zerlegung eines produktiven SaaS-Monolithen in Module oder Services, und keiner veröffentlicht eine Dauer, eine Deployment-Frequenz, Kosten oder ein Performance-Ergebnis für solche Arbeit. Die obige Methode stammt aus den zitierten Quellen und allgemeiner Engineering-Praxis, nicht aus einem messbaren Netbase-Ergebnis.

Alternativen: Wer führt die Arbeit durch

Vier Kriterien entscheiden: ob Tests und Monitoring existieren, wie viele Personen den alten Code verstehen, wie viel Roadmap-Arbeit während des Umbaus weiterlaufen muss und wer die Architektur danach verantworten muss. Netbase beginnt mit einem Architekturreview zu Mandantenfähigkeit, Abrechnung, Sicherheit und Kosten und plant dann die Slices. In der Custom-Entwicklung von Netbase gehört das geschaffene IP dem Kunden, und die meisten Projekte laufen nach Festpreis-Verträgen, die nach einer Discovery vereinbart werden. Das Angebot liegt bei SaaS-Entwicklung und Cloud Platform Engineering.

Grenzen dieses Leitfadens

• Jede Codebasis ist anders; die erste Abhängigkeitskarte ändert oft den Plan.
• Frameworks und Sprachen bieten unterschiedliche Werkzeuge zur Durchsetzung von Grenzen; prüfen Sie, was Ihrer unterstützt.
• Quellen werden für das zitiert, was sie dokumentieren; es werden keine Geschwindigkeits-, Kosten- oder Zuverlässigkeitswerte behauptet.

Nächster Schritt

Schildern Sie uns, wie das Produkt heute deployed ist, wie viele Teams es ändern und welcher Teil am meisten schmerzt – dann vereinbaren wir ein Lösungsreview, um die Nahtstellen zu kartieren und das erste Modul vorzuschlagen. Sie können auch weitere Netbase Insights lesen.

Verwandte Leistungen und Lösungen