Warum wir uns gegen Microservices und für einen modularen Monolithen mit Camunda 7 entschieden haben

Original: LinkedIn-Artikel. Englische Version: Medium-Artikel.

In meinem letzten Kunden-Projekt bei einer staatlichen Organisation standen wir vor einer Situation, die in vielen Digitalisierungsprojekten ähnlich ist. Es gibt ein kleines, motiviertes Projektteam, aber nur begrenzte Kapazitäten auf Kundenseite. Gerade bei der Automatisierung von Verwaltungsprozessen ist das ein entscheidender Faktor. Die Herausforderung besteht nicht nur darin, Prozesse fachlich korrekt abzubilden, sondern sie auch mit vertretbarem Aufwand produktiv zu betreiben und über mehrere Jahre weiterzuentwickeln.

Gleichzeitig war früh klar, dass zusätzliche Infrastruktur keine realistische Option ist. Komplexe Plattform-Komponenten erzeugen Betriebs- und Abstimmungsaufwände, die das Projektteam weder fachlich noch organisatorisch sinnvoll hätte tragen können. Wir mussten also eine Lösung finden, die ein kleines Team eigenständig entwickeln, ausrollen und weiterentwickeln kann.

Worauf wir optimiert haben

Unsere wichtigste Zielgröße war eine kurze Time-to-Value. Das Projekt sollte nicht erst nach langer Vorarbeit einen Nutzen erzeugen, sondern möglichst schnell erste Prozesse automatisieren. Gerade in einem Umfeld mit begrenzten Kapazitäten ist das wichtig, weil frühe Ergebnisse Vertrauen schaffen und den Weg für weitere Prozesse ebnen.

Genauso wichtig war Team-Autonomie. Wir wollten die Abhängigkeit von zusätzlicher Infrastruktur und komplexen Betriebsmodellen so klein wie möglich halten. Ein kleines Team kann viel erreichen, wenn es seinen Tech-Stack vollständig versteht und selbst beherrschen kann. Es wird aber schnell ausgebremst, wenn jede technische Entscheidung neue Plattformen, Spezialwissen oder zusätzliche Betriebsverantwortung nach sich zieht.

Der dritte Optimierungsfaktor war Flexibilität. Die Lösung sollte nicht nur kurzfristig funktionieren, sondern auch später anpassbar bleiben. Dazu gehört für uns vor allem die Trennung von Fachlichkeit und Technik sowie die Möglichkeit, technische Komponenten bei Bedarf auszutauschen, ohne die gesamte Anwendung neu denken zu müssen.

Unsere Architektur

Auf dieser Basis haben wir uns für einen modularen Monolithen (einen Modulithen) im Backend sowie ein React-Frontend entschieden. Im Backend lief eine Spring-Boot-Anwendung mit eingebetteter Workflow-Engine. Diese Betriebsform war für uns ein guter Kompromiss zwischen fachlich sauber strukturiert, aber operativ deutlich einfacher beherrschbar als ein verteiltes Setup mit mehreren eigenständigen Services und zusätzlichen Infrastruktur-Komponenten.

Für die fachliche Zusammenarbeit war BPMN ein zentraler Baustein. Mit BPMN konnten wir Prozesse gemeinsam mit den Fachabteilungen modellieren und anschließend in der Camunda 7 Engine automatisieren. Genau dieses Biz-Tech-Alignment war für uns wichtig, um die Anforderungen an den jeweiligen Anwendungsfall zu verstehen. Der Prozess sollte nicht in einem Fachkonzept beschrieben und später separat implementiert werden, sondern als gemeinsames Artefakt zwischen Fachbereich und Entwicklung dienen.

Die fachliche Struktur der Anwendung haben wir mit DDD abgebildet. Das war im staatlichen Kontext besonders hilfreich, weil Regeln, Begriffe und Abläufe sehr stark von der jeweiligen Domäne geprägt sind. Statt eine generische Plattform zu bauen, die alle Fälle irgendwie abdeckt, haben wir die Fachlichkeit explizit in der Anwendung modelliert. Jede Domäne bekam dafür ihr eigenes Modul im Modulithen.

Ergänzt wurde die fachliche Struktur mit DDD durch eine hexagonale Architektur, die dabei hilft die Domäne vor technischen Details zu schützen und Infrastruktur sauber über Ports und Adapter zu abstrahieren. Das macht die Anwendung verständlicher und reduziert die Gefahr, dass fachliche Logik über Zeit mit Framework-, Datenbank- oder Integrationscode vermischt wird.

Ein besonders wichtiger Punkt war für uns außerdem die Abstraktion der Workflow-Engine. Um schnell Ergebnisse liefern zu können haben wir bewusst auf eine Camunda 7 Engine gesetzt. Die technischen Abhängigkeiten zur Engine haben wir über die Process-Engine-API Bibliothek der BPM-Crafters gekapselt. Damit haben wir die Kopplung an eine konkrete Engine bewusst reduziert, um eine technische Austauschbarkeit zu gewährleisten und einen Wechsel der Engine zu erleichtern.

Trade-offs

Die Wahl von Camunda 7 war eine bewusste Trade-off-Entscheidung. Uns war klar, dass Camunda 7 sich dem End of Life nähert. Der Kunde war skeptisch gegenüber Software as a Service Lösungen und gleichzeitig war ein On-Premise-Betrieb von Camunda 8 im Kontext des Projekts nicht realistisch, weil dafür zusätzliches Betriebs-Know-how und Infrastruktur-Kapazität nötig gewesen wären. Die Nachhaltigkeit der Camunda 7 Forks war zu Projektstart noch nicht absehbar. Wir haben deshalb die für das Projekt pragmatischere Lösung gewählt und gleichzeitig mit hexagonaler Architektur und der Process-Engine-API dafür gesorgt einen späterer Austausch der Engine nicht unnötig zu erschweren.

Ein weiterer Trade-off ergibt sich aus dem Modulithen selbst. Obwohl die Domänen fachlich klar getrennt sind, betrifft jeder Release weiterhin das gemeinsame Backend-Artefakt. Das reduziert die operative Komplexität, bedeutet aber auch, dass Releases über Domänengrenzen hinweg koordiniert werden müssen. Ein schlanker gemeinsamer Release-Prozess ist damit kein Nice-to-have, sondern Voraussetzung.

Dazu kommt, dass sich einzelne Module nicht unabhängig voneinander skalieren lassen. Solange die Domänen ähnliche Lastprofile haben, ist das in vielen Fällen unkritisch. Wenn sich diese Profile stark unterscheiden, wird eine gemeinsame Deployment-Einheit aber schnell zum Nachteil.

Darüber hinaus haben wir uns bewusst gegen eine generische Prozessautomatisierungs- bzw. Low-Code-Plattform entschieden. Das erhöht den Entwicklungsaufwand, weil neue Anforderungen aktiv umgesetzt werden müssen. Im Gegenzug haben wir deutlich mehr Präzision in der Umsetzung und stoßen seltener an Grenzen, die bei generischen Tools oder Low-Code-Ansätzen schnell sichtbar werden.

Wann anders entscheiden

Diese Architektur ist nicht universell richtig. Ich würde anders entscheiden, wenn viele unabhängige Teams parallel Prozesse entwickeln, wenn Domänen sehr unterschiedliche Skalierungsprofile haben oder wenn unabhängige Deployments zwingend notwendig sind. Auch stark voneinander abweichende Release- und Freigabeprozesse zwischen Domänen sprechen eher gegen ein gemeinsames Backend-Artefakt.

Ebenso würde ich einen anderen Ansatz wählen, wenn Citizen Developer Prozesse eigenständig umsetzen sollen. Dann verschieben sich die Optimierungsziele von fachlich präziser codebasierter Umsetzung durch ein Entwicklungsteam hin zu stärker standardisierten Plattform- und Self-Service-Ansätzen.

Für den Kontext des Projekts war der gewählte Stack für uns trotzdem die richtige Entscheidung. Nicht, weil dieser in der Theorie am elegantesten war, sondern weil er zur Realität des Projekts gepasst hat: kleines Entwicklungsteam, begrenzte Infrastruktur, hohe fachliche Anforderungen und der Wunsch, schnell Mehrwert zu schaffen.

Wenn ihr schon einmal zwischen fachlicher Flexibilität, geringer Betriebs-Komplexität und technologischer Zukunftssicherheit abwägen musstet, würde mich eure Erfahrung interessieren. Welche Trade-offs haben sich in euren Projekten als richtig herausgestellt und welche eher nicht?