Ich sitze gerade an einem kleinen Tool und habe mich für eine monolithische Architektur entschieden, einfach weil es am Anfang überschaubar war. Jetzt, wo es langsam wächst, spüre ich diese eine, große Einschränkung immer mehr: Jede Änderung, und sei sie noch so klein, bedeutet einen kompletten Neustart des gesamten Systems für ein Update. Das fängt an, den Entwicklungsfluss richtig zu bremsen. Ich frage mich, ob andere diesen Punkt auch so deutlich erleben und wie sie dann weitermachen.
Diese monolithische Architektur wächst dir langsam über den Kopf. Jede winzige Änderung erfordert den ganzen Neustart und der Entwicklungsfluss stockt deutlich.
Aus analytischer Sicht macht der Monolith am Anfang Sinn weil alles gut zusammenhängt. Mit dem wachsenden Codebestand wird die Kopplung dichter und ein Update zieht oft mehr nach sich als geplant.
Vielleicht lohnt es sich die Sache anders zu denken statt gleich ein neues Muster zu fordern. Man könnte zuerst die Verantwortlichkeiten besser trennen innerhalb des bestehenden Codes.
Ich frage mich ob der Wechsel zu einer neuen Architektur wirklich die Grenzen verschiebt oder nur die Sicht darauf verändert?
Man könnte das Thema neu rahmen indem man Deployments betont statt die Architektur zu wechseln. Feature Flags und klare Grenzen im Monolithen könnten helfen ohne große Umbaumaßnahmen.
Ich habe den Eindruck dass kleine Schritte im Rahmen des Monolithen funktionieren. Vielleicht reicht es erst mal ein Refactoring der Module ohne neue Kommunikationswege zu erzwingen.
