Modularität ist kein Selbstzweck

Über Softwarearchitektur lässt sich erstaunlich leicht abstrakt sprechen. Schichten, Patterns, Abhängigkeiten und Regeln können schnell wichtiger wirken als das Produkt, für das sie eigentlich existieren.

Für mich ist die praktischste Frage deshalb eine andere: Wie schwer ist die nächste sinnvolle Änderung?

Wenn eine kleine Produktentscheidung plötzlich fünf nicht zusammengehörige Bereiche berührt, ist das meistens ein Signal. Wenn sich dagegen ein Teil verändern lässt, ohne dass der Rest des Systems seine Stabilität verliert, ist die Architektur wahrscheinlich näher an dem, was sie leisten soll.

Modularität schafft Beweglichkeit

Modularität bedeutet nicht, möglichst viele Ordner, Packages oder Interfaces zu erzeugen. Eine schlechte Grenze wird nicht besser, nur weil sie einen eigenen Namen bekommen hat.

Gute Module bündeln Dinge, die aus demselben Grund verändert werden. Gleichzeitig halten sie Details voneinander fern, die sich unabhängig entwickeln können sollten.

Das Ziel ist Beweglichkeit. Eine neue Idee soll nicht daran scheitern, dass frühere Entscheidungen überall im Code verteilt sind.

Clean Architecture als Werkzeug

Auch „Clean Architecture" ist für mich kein Regelbuch, das unabhängig vom Projekt umgesetzt werden muss. Die zugrunde liegenden Gedanken sind wertvoll: Abhängigkeiten bewusst gestalten, Domänenlogik nicht mit Infrastruktur vermischen und technische Details austauschbar halten, wo ein Austausch realistisch sein könnte.

Aber jede zusätzliche Abstraktion hat Kosten. Sie muss verstanden, gepflegt und gerechtfertigt werden.

Die sauberste Architektur ist deshalb nicht die mit den meisten Schichten. Es ist die, deren Grenzen zum tatsächlichen Produkt passen.

Frontend und Backend sind ein System

Gerade bei modernen Webanwendungen ist es verführerisch, Frontend und Backend als zwei vollständig getrennte Welten zu betrachten. Für die Nutzer existiert diese Grenze jedoch nicht.

Ein Datenmodell beeinflusst die Oberfläche. Eine Ladezeit beeinflusst Interaktion. Eine API-Entscheidung kann bestimmen, wie gut sich ein Zustand im UI ausdrücken lässt.

Deshalb gehört für mich zu sauberer Architektur auch, diese Übergänge bewusst zu gestalten.

Architektur ist ein Versprechen an die Zukunft

Man kann nicht alle zukünftigen Anforderungen kennen. Der Versuch, sie trotzdem vorwegzunehmen, führt häufig zu überabstrahierten Systemen.

Was man aber tun kann: heutige Entscheidungen so treffen, dass sie morgen noch verständlich sind.

Das ist der Wert von Modularität. Nicht Perfektion. Nicht maximale Flexibilität. Sondern die Fähigkeit, ein Produkt weiterzuentwickeln, ohne bei jeder guten neuen Idee Angst vor dem eigenen Code zu bekommen.