Wir schreiben das Jahr 2026 und die hitzigste Architekturdebatte des letzten Jahrzehnts scheint eine Phase des pragmatischen Reifegrades erreicht zu haben. Wenn es um Monolith vs. Microservices geht, hat die Industrie endlich aufgehört, blindem Hype zu folgen, und konzentriert sich stattdessen auf ROI (Return on Investment) und operative Effizienz. Für ein KMU oder ein Softwarehaus, das B2B-CRM-Lösungen entwickelt (wie im Fallbeispiel BOMA), ist die Wahl der Architektur nicht nur technischer, sondern strategischer Natur.

In diesem ausführlichen technischen Leitfaden analysieren wir, warum der Ansatz reiner Microservices oft eine Falle für agile Teams darstellt und wie der modulare Monolith die definitive Lösung darstellt, um Entwicklungsgeschwindigkeit, Wartbarkeit und Skalierbarkeit in Einklang zu bringen.

1. Monolith vs. Microservices: Die operative Realität im Jahr 2026

Jahrelang lautete das vorherrschende Narrativ: “Der Monolith ist die Vergangenheit, Microservices sind die Zukunft”. Die Praxiserfahrung hat jedoch gezeigt, dass Microservices für die meisten Unternehmensanwendungen, insbesondere im CRM-Kontext für KMU, eine unhaltbare akzidentelle Komplexität einführen.

Die versteckten Kosten von Microservices

Die Einführung einer Microservices-Architektur erfordert einen enormen infrastrukturellen Overhead. Es geht nicht nur um das Schreiben von Code, sondern um das Management von:

• Netzwerklatenz: In-Process-Aufrufe werden zu RPC/HTTP-Aufrufen, was Fehlerquellen und Latenzen einführt.
• Eventual Consistency: Das Management verteilter Transaktionen (Saga-Pattern) ist exponentiell komplexer als die ACID-Transaktionen einer relationalen Datenbank.
• Observability: Notwendigkeit komplexer Tools für Distributed Tracing (z. B. OpenTelemetry), um zu verstehen, wo eine Anfrage fehlschlägt.

Wie Martin Fowler bereits in den frühen 2020er Jahren betonte, bleibt die goldene Regel bestehen: “Verwende keine Microservices, es sei denn, du hast einen spezifischen Grund dafür”. Für ein CRM, das Stammdaten, Rechnungen und Tickets verwalten muss, führt die physische Trennung der Dienste oft zu einem verteilten Monolithen: das Schlechteste aus beiden Welten, wo man die Starrheit des Monolithen und die Komplexität verteilter Systeme hat.

2. Der modulare Monolith: Der architektonische “Sweet Spot”

Die Antwort für die Entwicklung von Software wie BOMA liegt im modularen Monolithen. Aber was bedeutet das genau?

Ein modularer Monolith ist eine einzelne Deployment-Einheit (ein einziges Artefakt, z. B. eine .jar-Datei oder ein einzelnes Docker-Image), in der der Code intern in hoch kohäsive und lose gekoppelte Module strukturiert ist. Im Gegensatz zum “Spaghetti-Monolithen” (Big Ball of Mud) werden hier die Abhängigkeiten streng kontrolliert.

Vorteile für ein agiles Team

• Vereinfachtes Refactoring: Das Verschieben von Code zwischen Modulen ist eine IDE-Operation, keine Systemmigration.
• Atomares Deployment: Eine einzige CI/CD-Pipeline veröffentlicht die gesamte Anwendung, wodurch Versionierungsprobleme zwischen Diensten eliminiert werden.
• Performance: In-Memory-Kommunikation mit Null-Latenz zwischen den Modulen.

3. Domain-Driven Design (DDD) und Bounded Contexts

Um einen effektiven modularen Monolithen zu bauen, ist die Anwendung der Prinzipien des Domain-Driven Design (DDD) obligatorisch. Wir müssen die Bounded Contexts (abgegrenzte Kontexte) identifizieren, aus denen unser CRM besteht.

Stellen wir uns die Architektur von BOMA unterteilt in drei Hauptmodule vor:

1. Core/CRM-Modul: Verwaltung von Stammdaten, Leads, Verkaufschancen.
2. Abrechnungsmodul: Verwaltung von Angeboten, Rechnungen, wiederkehrenden Zahlungen.
3. Ticketing-Modul: Kundensupport, SLAs, Problemlösung.

Definition der öffentlichen Schnittstellen

Die Grundregel lautet, dass kein Modul direkt auf die internen Klassen oder Datenbanktabellen eines anderen Moduls zugreifen darf. Die Kommunikation erfolgt ausschließlich über öffentliche Schnittstellen (interne APIs).

// Beispiel für einen Verstoß (BAD PRACTICE)
var fatture = _invoiceRepository.GetByCustomerId(customer.Id);

// Korrektes Beispiel im modularen Monolithen (GOOD PRACTICE)
// Das CRM-Modul ruft eine öffentliche Schnittstelle des Abrechnungsmoduls auf
var fatture = _invoiceModuleApi.GetInvoicesForCustomer(customer.Id);

4. Datenmanagement: Logische vs. physische Trennung

Einer der häufigsten Fehler in der Debatte Monolith vs. Microservices betrifft die Datenbank. Im modularen Monolithen müssen wir, obwohl wir eine einzige physische Datenbankinstanz haben (um Kosten zu sparen und Backups zu erleichtern), eine strikte logische Trennung durchsetzen.

Schema-Strategie (Schema-per-Module)

Wenn wir PostgreSQL oder SQL Server verwenden, muss jedes Modul sein eigenes Datenbankschema besitzen:

• crm_module.customers
• billing_module.invoices
• support_module.tickets

Es ist verboten, JOINs zwischen Tabellen verschiedener Schemata durchzuführen. Wenn das Abrechnungsmodul Kundendaten benötigt, um eine Rechnung zu drucken, muss es:

1. Die Daten über die interne API des CRM-Moduls anfordern.
2. Oder eine lokale redundante Kopie der benötigten Daten (z. B. Firmenname, USt-IdNr.) vorhalten, die durch In-Process-Domänenereignisse (Domain Events) aktualisiert wird.

5. Code-Refactoring: Von Schichten zu Features

Die Ordnerstruktur ist der Spiegel der Architektur. Wir verabschieden uns von der klassischen Aufteilung nach technischen Schichten (Controllers, Services, Repositories) zugunsten einer Aufteilung nach Modulen/Features.

Empfohlene Verzeichnisstruktur

/src
  /Modules
    /Crm
      /Api (Öffentliche Verträge, die anderen Modulen offengelegt werden)
      /Core (Interne Implementierung: Domain, Infra, App Services)
    /Billing
      /Api
      /Core
    /Ticketing
      /Api
      /Core
  /Shared (Geteilter Kernel, Event Bus, übergreifende Utilities)
  /Host (Einstiegspunkt, Startup, DI-Konfiguration)

Dieser Ansatz ermöglicht es verschiedenen Teams, an unterschiedlichen Modulen zu arbeiten, ohne sich gegenseitig auf die Füße zu treten, wodurch die Unabhängigkeit von Microservices simuliert wird, aber die Einfachheit des Monolithen erhalten bleibt.

6. CI/CD-Deployment-Strategien

Der modulare Monolith zeichnet sich durch hohe Iterationsgeschwindigkeit aus. So konfigurieren Sie eine moderne CI/CD-Pipeline für dieses Szenario:

• Einziger Build: Die Kompilierung überprüft die Integrität aller Module gleichzeitig. Wenn eine Änderung im CRM-Modul das Abrechnungsmodul beschädigt, schlägt der Build sofort fehl (schnelle Feedback-Schleife).
• Automatisierte Tests:
  • Unit Tests: Isoliert innerhalb jedes Moduls.
  • Integration Tests: Überprüfen die Funktion des Moduls mit der Datenbank (in ephemeren Containern).
  • Architecture Tests: Verwendung von Bibliotheken wie ArchUnit oder NetArchTest, um per Code zu verhindern, dass Modul A interne Klassen von Modul B verwendet.
• Blue/Green Deployment: Da es sich um ein einzelnes Artefakt handelt, ist es einfach, die neue Version neben der alten hochzufahren, den Traffic umzuschalten und im Fehlerfall sofort ein Rollback durchzuführen.

Fazit: Wann migrieren?

Der Übergang vom modularen Monolithen zu Microservices sollte erst erfolgen, wenn ein einzelnes Modul so komplex wird oder so unterschiedliche Ressourcen erfordert (z. B. ein KI-Modul, das GPUs benötigt), dass seine Auslagerung in einen autonomen Dienst gerechtfertigt ist.

Bis zu diesem Zeitpunkt bleibt der modulare Monolith für die Entwicklung von CRM- und Verwaltungssoftware in KMU die effizienteste, wirtschaftlichste und robusteste Architektur. Er ermöglicht es, heute sauberen Code zu schreiben und die Tür für eine physische Verteilung in der Zukunft offen zu lassen, ohne den Preis der Komplexität im Voraus zu zahlen.

Häufig gestellte Fragen