Von Microservices zum Modulithen

In vielen Entwicklungsprojekten, in denen ich im Laufe der letzten Jahre mitwirken durfte, hatte man sich bei der Umsetzung für eine Microservice- oder Self-Contained Systems Architektur entschieden. Wenn man im Rahmen der fachlichen Analyse und Modellierung mehrere, weitestgehend voreinander unabhängige Subsysteme identifiziert hat, scheint das die naheliegendste Architekturform zu sein. Allerdings bringt sie einige Nachteile mit sich, die sich negativ auf die Entwicklungsgeschwindigkeit und die Flexibilität auswirken können. Subsysteme sind i. d. R. nicht völlig unabhängig. Irgendwelche Abhängigkeiten zwischen ihnen muss es immer geben, und die werden schnell unhandlich und damit teuer in der (Weiter-) Entwicklung.

Ein Modulith, also eine monolythische Applikation, die intern in sauber getrennte Module aufgeteilt ist, würde vielleicht denselben Zweck erfüllen und wäre dabei vermutlich deutlich einfacher zu handhaben. Wie würde ein solcher Modulith aber intern aussehen? Genauso strukturiert, wie die existierenden getrennten Services, nur alles in einem Repository und ohne den ganzen Overhead an den Modul-Schnittstellen? In einem Experiment habe ich versucht, die Domäne aus einem meiner Projekte in Form eines solchen Modulithen neu umzusetzen. Dabei bin ich über eine Reihe erwarteter, aber auch über einige unerwartete Design-Fragestellungen gestolpert. Im Vortrag stelle ich einige dieser Fragestellungen sowie meine persönlichen Learnings vor.

Von Microservices zum Modulithen

TAGS