Letztes Jahr saß ich beim Erstgespräch mit einem Maschinenbauer, 180 Mitarbeitende, Schwaben, dritte Generation. Der Entwickler — einer, nicht viele — hatte das hauseigene ERP vor vier Jahren "sauber modular" aufgebaut. Auftragsmodul hier, Katalogmodul da, alles über Events entkoppelt. Lehrbuch.
Ich fragte ihn, wie viele dieser Modul-Grenzen heute noch so gezogen sind, wie er sie ursprünglich entworfen hat. Er hat kurz nachgedacht. Dann: "Keine einzige." Und er hatte das gar nicht kommen sehen, weil jede einzelne Änderung, die die Grenze aufgeweicht hat, für sich genommen vollkommen vernünftig war.
Was Milan Jovanović beschreibt
Milan schreibt über einen Rewrite eines 40 Jahre alten Manufacturing-ERPs. Er zieht eine klassische Grenze: ein Katalog-Modul (Produkte, Konfigurationen, Preise) und ein Kollaborations-Modul (der Prozess, in dem Händler und Kunden gemeinsam eine Bestellung aufbauen). Asynchrone Event-Kommunikation zwischen beiden — architektonisch sauber, während der Migration bewährt.
Ein Jahr später ist die Grenze in der Ordnerstruktur noch vorhanden, in der Praxis nicht mehr. Feature für Feature hat sich Kollaboration Daten aus dem Katalog geholt, dann Live-Preise, dann sofortige Konsistenz bei Konfigurationsänderungen gebraucht. Eventual Consistency funktioniert, bis das Business sagt: "Muss sofort stimmen, wenn der Händler auf Speichern klickt." An diesem Punkt sind synchrone Calls, geteilte Transaktionen und Workarounds eingezogen — und zwei Module, die eigentlich getrennt bleiben sollten, faktisch eins.
Milans Fazit: Modul-Grenzen sind Vermutungen, die du mit dem geringsten Wissen über das System triffst. Fang mit wenigen, gröberen Modulen an. Lass Konsistenz-Anforderungen die Grenzen ziehen, nicht das Org-Chart.
Das ist gut beobachtet. Aber es beschreibt ein Team von mehreren Entwicklern, ein Budget für einen Mehrjahres-Rewrite, und einen Kontext, in dem Architektur-Entscheidungen überhaupt diskutiert werden.
Wie das im KMU mit 30–300 Mitarbeitenden wirklich landet
Der Unterschied zu dem, was ich in Mittelstands-Mandaten sehe, ist nicht die Architektur. Der Unterschied ist die Geschwindigkeit, mit der Kontext verloren geht, und die Abwesenheit eines zweiten Gehirns, das das merkt.
Bei Milan gibt es ein Team. Wenn eine Modul-Grenze sich zu verschieben beginnt, hat zumindest theoretisch jemand die Chance, es zu benennen. Im Mittelstand gibt es oft einen Entwickler, manchmal zwei. Wenn der eine im Urlaub ist, trifft der andere eine Entscheidung über eine Modul-Grenze, ohne zu wissen, dass er das gerade tut. Drei Monate später weiß niemand mehr, warum das Preisberechnungs-Flag plötzlich im Auftragsmodul liegt.
Dazu kommt: Die meisten KMUs, bei denen ich reingehe, haben noch keine Modul-Grenzen im Sinne von Milan. Sie haben ein gewachsenes System, das über Jahre durch Feature-Requests geformt wurde, und eine Handvoll Entwickler, die das System in- und auswendig kennen — aber nur so lange, bis einer davon geht. Was Milan rückblickend als "die Grenze, die ich nicht zurücknehmen konnte" beschreibt, ist für viele Mittelständler der Normalzustand. Nicht als Resultat einer bewussten Architektur-Entscheidung, sondern weil die Grenze nie bewusst existiert hat.
Das Muster, das ich immer wieder sehe, ist dieses: Ein Modul-Schnitt wird gemacht, wenn das Unternehmen wächst und ein zweiter Entwickler eingestellt wird. Jeder bekommt "seinen Bereich". Dann tritt die Führungskraft mit einer Anforderung an, die beide Bereiche betrifft. Keiner der zwei Entwickler hat die Autorität zu sagen "das bricht unsere Architektur". Das Ticket wird gebaut, die Grenze wird weich. Und niemand hat einen Rückgrat-Moment, weil es keinen formalisierten Ort gibt, an dem Architektur-Entscheidungen getroffen werden.
Was von Milans Rat wirklich zählt — und was ich anders betone
Milans wichtigster Satz ist dieser: "Eventual Consistency across a boundary is a bet that the two sides never need to be immediately consistent. Make that bet on purpose, not by default."
Das ist der Satz, den ich aus diesem Artikel nehme. Nicht die Frage Monolith vs. Services. Nicht die Frage Event-driven vs. synchron. Sondern: Weißt du, welche Konsistenz-Annahme in deinem System steckt, und hast du sie bewusst getroffen?
Im Mittelstand ist die Antwort fast immer nein. Die Annahme ist nicht getroffen worden, sie ist entstanden. Und das ist das eigentliche Risiko.
Was Milans Artikel nicht adressiert — und was ich für den KMU-Kontext ergänzen würde:
Erstens: Dokumentiere die Annahme, nicht die Entscheidung. Ein Architecture Decision Record (ADR) klingt nach Enterprise-Overhead. Aber ein Kommentar im Code, der sagt "Wir nehmen hier in Kauf, dass Preis und Konfiguration für max. 30 Sekunden auseinanderlaufen können — weil das Business das akzeptiert hat (Stand: März 2025)" — das kostet fünf Minuten und rettet dir ein Jahr später den Abend.
Zweitens: Fang nicht mit Event-Driven an, wenn du noch keine synchronen Grenzen sauber hast. Event-Driven Architecture ist nicht falsch, aber sie versteckt Konsistenz-Probleme hinter scheinbar sauberem Entkopplung. Ich habe Systeme gesehen, in denen Events als De-facto-Datenbank benutzt wurden, weil niemand mehr sicher war, welches Modul der "Owner" eines Datums ist. Das ist teurer zu reparieren als ein enger Coupling, der wenigstens sichtbar ist.
Drittens: Milans Empfehlung "Fang mit wenigen, gröberen Modulen an" ist für den Mittelstand die wichtigste. Nicht weil grobe Module besser sind, sondern weil du im KMU meistens nicht die Bandbreite hast, eine zu früh gezogene Grenze sauber wieder zusammenzuführen. Ein Modul, das du zu früh splittest, wird nicht elegant gemergt. Es wird mit workarounds verbunden, die dann zehn Jahre bestehen bleiben.
Die eine konkrete Empfehlung
Wenn du heute ein System für einen Mittelstandskunden baust oder restrukturierst: Zeichne zuerst die Konsistenz-Karte, nicht die Domain-Karte. Welche Daten müssen in Echtzeit zusammenpassen? Welche dürfen fünf Minuten auseinanderlaufen? Welche dürfen einen Tag auseinanderlaufen?
Die Grenzen, wo Echtzeit-Konsistenz gebraucht wird, sind deine Nicht-Grenzen. Dort ziehst du keinen Modul-Schnitt, egal wie verschieden die Domains inhaltlich aussehen. Die Grenzen, wo Daten asynchron auseinanderlaufen dürfen, sind deine echten Kandidaten.
Das klingt simpel. Es ist auch simpel. Aber ich kenne kein einziges Mittelstands-Projekt, in dem diese Frage systematisch gestellt wurde, bevor die erste Zeile Code geschrieben war.
Der vollständige Original-Beitrag von Milan Jovanović: The Modular Monolith Boundary I Couldn't Take Back
Wenn du gerade dabei bist, ein System zu strukturieren, oder merkst dass eine bestehende Grenze nicht mehr hält — ich mache das seit Jahren mit Mittelstandskunden durch. Kein Deck, kein Konzept, sondern Klartext.
— Bernhard