Komplexität entfernen statt hinzufügen

Fortschritt wird meist mit Hinzufügen gleichgesetzt: mehr Funktion, mehr Bausteine, mehr Fähigkeit. Diese Geschichte handelt von einem Fortschritt, der aus Wegnehmen bestand. Sie ist bewusst allgemein gehalten — ohne System, ohne Beteiligte, ohne Zeitpunkt.

Situation

In einem Monolithen steckten externe API-Bausteine fest eingebettet — Teile, die mit fremden Diensten sprachen, verwoben mit dem übrigen Code des Systems. Sie taten ihre Arbeit, aber sie waren Teil eines großen Ganzen, das nur als Ganzes zu bewegen war. Alles hing an allem.

Ausgangsannahmen

Die eingebettete Bauweise war einmal die naheliegende: Man schreibt den Zugriff auf einen externen Dienst dorthin, wo man ihn braucht, mitten in den Fluss des Systems. Für den ersten Bedarf ist das schnell und richtig. Die stille Annahme war, dass zusammengehört, was zusammen geschrieben wurde — dass Nähe im Code auch Nähe in der Sache bedeutet.

Problem

Über die Zeit wurde diese Nähe zur Last. Weil die API-Bausteine im Monolithen steckten, teilten sie dessen Schicksal: Sie ließen sich nicht getrennt betreiben, nicht getrennt skalieren, nicht ändern, ohne das Ganze zu berühren. Ein Baustein, der unter Last mehr Ressourcen gebraucht hätte, bekam sie nur, indem man das ganze System vergrößerte. Die Verflechtung kostete an einer Stelle, an der niemand sie beim Schreiben vermutet hatte: in der Beweglichkeit.

Ursache

Die Ursache war, dass Nähe im Code mit Zusammengehörigkeit verwechselt worden war. Die API-Bausteine sahen aus wie Teil des Systems, weil sie darin geschrieben standen — aber ihrer Natur nach waren sie eigenständig: klar abgegrenzte Aufgaben mit einer klaren Grenze nach außen. Sie gehörten nicht in den Monolithen; sie waren nur dort geschrieben worden.

Entscheidung

Die Entscheidung war, wegzunehmen statt hinzuzufügen — die eingebetteten Bausteine aus dem Monolithen herauszulösen und zu eigenständigen APIs zu machen. Kein neues Feature, keine zusätzliche Fähigkeit; nur eine Grenze dort gezogen, wo ohnehin eine war, aber keine sichtbar gemacht worden war.

Umsetzung

Die Bausteine wurden entlang ihrer natürlichen Grenze herausgetrennt und als eigenständige Dienste hinter einer klaren Schnittstelle neu aufgestellt. Das übrige System sprach sie nun über diese Grenze an, statt sie in sich zu tragen. Der Umbau fügte nichts hinzu, was das System vorher nicht konnte — er ordnete nur, was schon da war, entlang der Linien, an denen es wirklich getrennt gehörte.

Trade-offs

Das Herauslösen ist nicht gratis: Eine eigenständige API bringt eine eigene Grenze mit, die betrieben, überwacht und versioniert werden muss — mehr bewegliche Teile, nicht weniger. Der Gewinn ist an anderer Stelle: eine klarere Architektur und die Fähigkeit, jeden Baustein unabhängig zu betreiben und zu skalieren. Anders würden wir entscheiden, wenn die Bausteine wirklich untrennbar zum Kern gehörten — dann wäre das Herauslösen eine künstliche Grenze, die trennt, was zusammengehört.

Was wir gelernt haben

Komplexität zu entfernen ist oft wertvoller, als Funktion hinzuzufügen. Der sichtbare Fortschritt liegt im Hinzufügen, der eigentliche oft im Wegnehmen — im Auflösen einer Verflechtung, die niemand mehr bemerkte, weil sie immer da war. Ein System wird nicht dadurch besser, dass es mehr kann, sondern dadurch, dass klarer wird, was wozu gehört. Die Frage „was können wir hinzufügen?" ist die verlockende; die Frage „was gehört hier eigentlich nicht hin?" ist die wertvollere.

Wie das Batunet verändert hat

Seither prüfen wir bei einem verworrenen System zuerst, was sich entfernen oder herauslösen lässt, bevor wir überlegen, was sich hinzufügen ließe. Wir behandeln eine klare Grenze als Gewinn, auch wenn sie keine neue Fähigkeit bringt. Der eleganteste Umbau ist oft der, nach dem das System weniger, aber Geordneteres enthält.

Weiterführend

• Guide: Modularer Monolith vs. Microservices — wann eine Grenze zwischen Teilen sinnvoll ist und wann nicht.
• Decision: Modularer Monolith als Ausgangspunkt — Struktur entlang echter Grenzen, nicht aus Gewohnheit.
• Guide: API Design für langlebige Systeme — eine herausgelöste Fähigkeit sauber als Schnittstelle entwerfen.
• Opinion: Warum vorzeitige Abstraktion Komplexität schafft — warum nicht jede Grenze gut ist, sondern nur die entlang echter Trennlinien.

Grundlage ist die Batunet Engineering Method: Struktur entlang echter Grenzen ziehen, Verflechtung auflösen, das Wegnehmen ernst nehmen wie das Hinzufügen.

Nicht jedes Wachstum ist Fortschritt. Manchmal ist der beste Schritt, etwas aus dem Ganzen zu lösen, damit klarer wird, was wohin gehört.