# Modular Monolith Architektur Software Architektur ist eine Thematik welche mit dem Gang der Zeit immer mehr an Relevanz gewinnt. Die grösste Schwierigkeit dabei ist, dass sich mit der Entwicklung unserer Technologien auch die Anforderungen an unsere Software stetig verändern. Gerade in letzter Zeit hat die sogenannte Microservices Architektur an Aufmerksamkeit gewonnen, was viele Projekte dazu getrieben hat, auf diese Umzusteigen. Während Microservices durchaus mit Vorteilen kommen, unter anderem die grosse Flexibilität und Skalierbarkeit, ist diese nicht für jedes Projekt die richtige Wahl. Für viele Entwickler steht die Monolithische Alternative im Widerspruch mit dieser Flexibilität. In diesem Beitrag wollen wir uns jedoch eine Untergruppe der Monolithen ansehen, welche versucht einen Kompromiss zwischen diesen beiden Ansätzen zu bieten. Bevor wir uns jedoch mit dem Lösungsansatz beschäftigen, wollen wir uns fragen, was wir überhaupt zu lösen versuchen. Bei einer monolithischen Architektur mit beispielsweise Clean Architecture haben wir bereits eine gute Trennung der Aufgaben über die Schichten hinweg, müssen bei einer Erweiterung mit einem neuen Feature jedoch alle Schichten verändern. Während das in einem kleinen eingespielten Team noch funktionieren kann, wird es bei grösseren Teams zu einem Problem. Wenn parallel an verschiedenen Features gearbeitet wird, dann werden die gleichen Schichten verschieden angepasst, was zu Konflikten führen kann. Bei Microservices wird dieses Problem so gelöst, dass jedes Feature ein eigener "Service" ist und so unabhängig von einander implementiert werden kann. Auch die Skalierung ist so viel einfacher, da öfters genutzte Services unabhängig von den anderen skaliert werden können. Diese Vorteile kommen aber mit einem ziemlich hohen Preis, da jeder Service die ganze Infrastruktur neu implementieren muss. So hat man einerseits sehr viel Duplikation im Code, aber auch den Overhead beim Deployment. Zusammengefasst haben wir also zwei Extreme. Auf der einen Seite haben wir wenig Overhead und viel Wiederverwendung, wobei die Entwicklung in agilen Teams jedoch sehr schwierig wird. Auf der anderen Seite haben wir völlige Flexibilität und Skalierbarkeit, müssen dafür aber sehr viel Overhead und Duplikation in kauf nehmen. ## Modulare Monolithen Um einen möglichen Kompromiss der beiden Seiten zu finden wurde also die Modular Monolith Architektur entwickelt. Die Idee dabei ist, dass wir grundsätzlich eine monolithische Applikation bauen, innerhalb dieser jedoch in einzelne sogenannte "Module" unterteilen. ![[BlogModularMonolith.png]] *In diesem Diagramm ist eine mögliche Version der Modular Monolith Architektur ersichtlich[^2]* Wie im Diagramm ersichtlich, hat unsere Applikation jetzt keine übergreifenden Schichten mehr. Stattdessen unterteilen wir zuerst in Module, welche jeweils ihre eigenen Schichten enthalten. Es gibt dazu noch ein "Shared" Modul, welches denjenigen Code enthalten sollte, welcher von vielen Modulen genutzt wird. Mit diesem Ansatz versuchen wir, möglichst viele Vorteile von den beiden Grundansätzen zu kombinieren. Unsere Applikation ist ein Monolith, kann also in einer Umgebung veröffentlicht werden und es muss nur eine Infrastruktur eingerichtet werden. Dadurch, dass wir sie jedoch in Module unterteilen, kann problemlos parallel daran gearbeitet werden. Die Module sollten unabhängig von einander gestaltet werden, wobei eine Kommunikation zwischen Modulen nur über die effektive Schnittstelle geschehen sollte. Wir haben also gute Flexibilität mit wenig Overhead. Im obigen Diagramm wurde für alle Module die gleiche logische Abtrennung genutzt, namentlich die Layered Architektur. Man hat jedoch durchaus die Freiheit, in jedem Modul einen anderen Weg zu wählen. Auch die Datenbank muss nicht von allen geteilt werden. ## Strangler Fig Pattern Eine Würgefeige (engl. Strangler Fig) ist eine Pflanze welche im Regenwald gefunden werden kann. Während sie wächst bezieht sie Nahrung von ihrem Stammbaum, bis ihre Wurzeln den Boden erreichen. Sobald sie am Boden Wurzeln schlagen kann, ist sie eigenständig Lebensfähig.[^3] Martin Fowler sah eine solche Pflanze während einem Urlaub in 2001 und entwickelte daraus ein Entwurfsmuster mit entsprechendem Namen. Für uns ist dies relevant, da das Muster der Umwandlung einer monolithischen Applikation in Microservices dient. Die Idee ist dabei, dass einzelne Abschnitte isoliert ausgelagert und migriert werden. Ich erwähne es in diesem Beitrag, da die Modular Monolith Architektur sehr gut für diese Migration geeignet ist. Wir starten zwar mit einem Monolith, gestalten unsere Applikation jedoch von Anfang an so, dass jederzeit auf eine Microservices Architektur gewechselt werden kann. ## Fazit In diesem Beitrag haben wir eine neue Architektur kennen gelernt, welche versucht die Lücke zwischen Monolithen und Microservices zu schliessen. Wir haben gesehen, dass wir durch einen modularen Ansatz an Abgrenzung und Klarheit gewinnen, was bei der Entwicklung in grösseren Teams von grossem Vorteil sein kann. Dazu kommt, dass der Wechsel auf Microservices in der Zukunft jederzeit noch möglich ist, ohne, dass die ganze Applikation neu entwickelt werden muss. [^1]: vgl. Microservices Killer: Modular Monolithic Architecture, in: Medium, 25.06.2025, https://medium.com/design-microservices-architecture-with-patterns/microservices-killer-modular-monolithic-architecture-ac83814f6862 [^2]: vgl. Eigene Zeichnung [^3]: vgl. Strangler Fig, in: Martin Fowler, 25.06.2025, https://martinfowler.com/bliki/StranglerFigApplication.html