Microservices sind der Hammer, aber nicht alles ist ein Nagel. Trotzdem ist man leicht in der Versuchung, immer diesen Hammer auszupacken, wenn man eine gut modularisierte Software-Architektur zimmern will. Genau das hatten wir mit unserem System auch vor. Wir erzählen euch die Geschichte, warum wir unsere erste Entscheidung revidiert und mit modularen Monolithen ein passenderes Architektur-Werkzeug für uns gefunden haben.

Woran lässt sich erkennen, ob das jeweilige Architekturproblem in die Kategorie „Nagel“ fällt oder nicht? Das kommt auf die Rahmenbedingungen an: Hat man die Domain schon so gut verstanden, dass die Modellgrenzen oder „Bounded Contexts“ klar sind? Ist es wichtig, einzelne Bausteine unabhängig ausrollen zu können? Wenn nicht, können Modulare Monolithe anstelle von Microservices zwei Vorteile bringen: Erstens verbinden sie ein einfaches Deployment mit einer fachlichen Modularisierung. Damit gewinnt man die Flexibilität, den Code einfach umzubauen. Zweitens spart man sich den Verwaltungs-Overhead von Microservices, ohne dabei den Weg zu einer stärkeren Trennung zu verbauen.

Das klingt attraktiv, aber der Teufel steckt im Detail. Wie stellt man sicher, dass die einzelnen Module getrennt bleiben und kein „Big Ball of Mud“ entsteht? Wie kann man auf der anderen Seite eine Kommunikation zwischen den Modulen erlauben, um fachliche Abhängigkeiten abzubilden?

Wir zeigen euch an unserem System, wie wir die Trennung der fachlichen Module, aber auch die Kommunikation zwischen ihnen umgesetzt haben, auf welche Probleme wir gestoßen sind, welche Lösungen wir gefunden haben und welche Kompromisse wir eingegangen sind.

Damit möchten wir euch einen Eindruck vermitteln, welche Herausforderungen wir mit dem Werkzeug „Modularer Monolith“ meistern konnten, damit ihr es ebenfalls in euren Architektur-Werkzeugkoffer aufnehmen könnt.