Modularer Monolith: Ordnung ohne Microservices

Kurz: Eine Anwendung, die als eine Einheit läuft, intern aber in klar getrennte Module mit festen Schnittstellen aufgeteilt ist.

Genauer: Ein Monolith ist eine Anwendung, die als ein Programm gebaut und ausgeliefert wird. Das ist nicht automatisch schlecht: Er ist einfach zu entwickeln, zu testen und zu betreiben. Probleme entstehen, wenn alles mit allem verknüpft ist („Big Ball of Mud“). Der modulare Monolith vermeidet das durch klare Grenzen im Inneren, ohne die Last verteilter Systeme.

Im Detail

Idee

Die Anwendung wird nach Fachbereichen geschnitten, zum Beispiel Bestellung, Katalog, Zahlung, Benutzer (siehe Domain-Driven Design). Jedes Modul besitzt seine Daten und bietet anderen nur eine öffentliche Schnittstelle an. Zugriffe auf Interna und direkte Tabellenzugriffe über Modulgrenzen hinweg sind verboten.

Beispiel für Regeln

src/
  bestellung/   (öffentlich: index.ts, intern: db/, logik/)
  katalog/
  zahlung/

Ein Linter oder Architektur-Test (zum Beispiel ArchUnit, dependency-cruiser) lässt den Build fehlschlagen, wenn katalog auf bestellung/logik zugreift statt auf bestellung/index.

Vorteile gegenüber Microservices

Ein Aufruf zwischen Modulen ist ein normaler Funktionsaufruf, ohne Netzwerk, Zeitüberschreitungen oder verteilte Transaktionen. Eine Datenbanktransaktion kann mehrere Module umfassen. Es gibt nur eine Pipeline und ein Deployment. Für kleine Teams ist das oft die klügere Wahl.

Weg offen halten

Sind die Grenzen sauber, lässt sich ein Modul später bei Bedarf herauslösen und als eigener Dienst betreiben, zum Beispiel wenn es besonders stark skaliert werden muss. Das Gegenmittel zu einem schlechten Monolithen ist meist bessere Struktur, nicht sofort mehr Server.

Siehe auch: Microservices, Domain-Driven Design, Hexagonale Architektur