Wofür diese Seite steht

Ich mag gute Softwareentwicklung. Vor allem dann, wenn sie sich nicht wie Glücksspiel anfühlt.

Wenn ein System sauber geschnitten ist, Verantwortungen klar sind, Datenflüsse verständlich bleiben und Fachlichkeit einen erkennbaren Ort hat, verändert sich die Arbeit. Änderungen werden nicht automatisch einfach, aber sie werden nachvollziehbar. Man kann Entscheidungen erklären, Fehler eingrenzen und neue Anforderungen ergänzen, ohne jedes Mal das halbe System neu entdecken zu müssen.

Dann fühlt sich Softwareentwicklung wieder nach Handwerk an. Nicht nach Magie, Heldentum oder nächtlicher Feuerwehr, sondern nach einem Beruf, den man mit Erfahrung, Sorgfalt, guten Werkzeugen und klaren Entscheidungen ziemlich gut ausüben kann.

Genau dafür möchte ich auf dieser Seite etwas mehr Raum schaffen.

Woher ich komme

Mein Blick auf Architektur kommt vor allem aus Projekten.

Ich habe viele Jahre in regulierten Systemen gearbeitet. Dort reicht es nicht, dass Software heute funktioniert. Sie muss auch nachvollziehbar, wartbar, prüfbar und verantwortbar bleiben.

Ich habe Systeme nicht nur gebaut und abgegeben. Ich habe sie über Jahre weiterentwickelt, stabilisiert, erklärt, verteidigt und durch viele Änderungen begleitet.

Ob ein System wirklich gut ist, erkennt man deshalb selten am ersten Release. Interessant wird es nach drei, fünf oder sieben Jahren. Menschen sind gegangen, Anforderungen haben sich verändert, regulatorische Vorgaben sind dazugekommen und Teams sind gewachsen. Irgendwann weiß niemand mehr ganz genau, warum eine Entscheidung damals so getroffen wurde.

Wenn das System trotzdem noch verständlich und veränderbar ist, war vermutlich einiges richtig.

Ich habe erlebt, wie angenehm es ist, in solchen Systemen zu arbeiten. Ich kenne aber auch die andere Seite.

In einigen Projekten war ich der Feuerwehrmann, der gerufen wurde, wenn es schon brannte. Änderungen machten Angst, Komponenten wussten alles, Services entwickelten sich zu kleinen Betriebssystemen und Stores machten sehr viel, nur leider nichts besonders klar. Irgendwann konnte niemand mehr überzeugend sagen, wo die Fachlichkeit eigentlich lebt.

Die Systeme liefen noch. Das war oft schon das Positivste, was man über sie sagen konnte.

Diese Erfahrungen prägen meinen Blick auf Architektur. Nicht, weil ich glaube, alles besser zu wissen. Nach genug Bränden beginnt man nur irgendwann, Brandschutz ernster zu nehmen.

Warum diese Seite?

Frontend-Architektur wird aus meiner Sicht häufig entweder unterschätzt oder unnötig mystifiziert.

Für die einen ist es eben Frontend. Ein bisschen UI, etwas State, ein paar APIs und Komponenten. Wird schon.

Für die anderen beginnt Architektur dort, wo Diagramme, Prinzipien, Buzzwords und irgendein neues „Clean irgendwas“ auftauchen.

Beides greift zu kurz.

Frontend-Architektur ist für mich kein Selbstzweck und kein Schönheitswettbewerb. Sie besteht aus den Entscheidungen, die dafür sorgen, dass ein System auch morgen noch verstanden, verändert und verantwortet werden kann.

Diese Entscheidungen bestimmen mit, ob ein Team langfristig schnell bleibt oder nur am Anfang schnell wirkt. Sie entscheiden, ob Fachlichkeit sichtbar bleibt oder langsam in Komponenten, Services und Stores versickert. Neue Anforderungen können integriert werden oder einfach irgendwo hineingestopft werden.

Ein System kann wachsen. Es kann aber auch einfach nur dicker werden.

Auf dieser Seite möchte ich über diesen Unterschied schreiben. Konkret, manchmal deutlich und möglichst ohne Framework-Marketing. Meine Perspektive kommt dabei aus Systemen, die gut funktioniert haben, und aus solchen, bei denen irgendwann nur noch die Feuerwehr zuverlässig funktioniert hat.

Worüber ich hier schreiben will

Ich möchte keine weitere Seite bauen, die allgemeine Best Practices sammelt. Davon gibt es genug.

Mich interessieren die Stellen, an denen Architektur im echten Projektalltag trägt oder scheitert. Komponenten beginnen plötzlich, komplette Use Cases abzubilden. Services sammeln Verantwortung wie Staub. Stores vermischen Seiteneffekte, Business-Logik und ViewModels. Reaktive Datenflüsse werden durch imperative Abkürzungen immer schwerer nachvollziehbar. Microfrontends lösen keine fehlenden Grenzen, sondern verteilen sie im schlimmsten Fall nur auf mehrere Deployments.

Dazu kommen regulierte Systeme, in denen Nachvollziehbarkeit nicht optional ist, und Teams, die Qualität durchaus wollen, aber selten die Zeit bekommen, die Axt zu schärfen.

Mich interessiert aber genauso das Gegenteil. Klare Schnitte, gute Namen und kleine verständliche Kontexte machen einen enormen Unterschied. Fachliche Sprache hilft, Tests schaffen Vertrauen und Stores können sehr nützlich sein, wenn sie eine erkennbare Aufgabe haben. Gute Schnittstellen verraten nicht mehr Wissen als nötig. Und manchmal braucht ein Legacy-System keine perfekte Lösung, sondern zuerst eine vernünftige Brücke, die den nächsten Schritt überhaupt möglich macht.

Ich möchte deshalb nicht nur zeigen, was schlecht läuft. Interessanter ist die Frage, warum es passiert, woran man es erkennt und wie man wieder herauskommt.

Architektur ist Handwerk

Softwareentwicklung wird manchmal behandelt, als wäre sie eine Form von Magie. Das meiste davon ist deutlich unspektakulärer.

Gute Software entsteht oft durch ziemlich normale Dinge: klare Begriffe, nachvollziehbare Schnitte, gute Werkzeuge, Übung, Feedback, Mentoring, Erfahrung und die Disziplin, nicht jedes Problem mit einer besonders cleveren Idee lösen zu wollen.

Architektur ist für mich deshalb kein Elfenbeinturm. Sie ist handwerkliche Verantwortung auf Systemebene.

Natürlich muss ein Feature fertig werden. Architektur ergänzt diese Frage aber um weitere: Wo gehört diese Verantwortung hin? Was passiert bei der nächsten Änderung? Wie bleibt der Datenfluss verständlich? Welche Abhängigkeit entsteht gerade? Welche Entscheidung lässt sich später nur schwer korrigieren? Und wer muss diesen Code in zwei Jahren noch verstehen?

Das macht Entwicklung nicht automatisch langsam. Im besten Fall verhindert es nur, dass Geschwindigkeit mit kurzfristigem Durchsatz verwechselt wird.

Warum das mit KI noch wichtiger wird

KI-Tooling verändert Softwareentwicklung bereits heute deutlich.

Code lässt sich schneller erzeugen. Varianten werden billiger. Prototypen entstehen innerhalb kurzer Zeit. Coding Agents können Aufgaben analysieren, Dateien ändern, Tests ausführen, Vorschläge machen und inzwischen erstaunlich große Änderungen durch ein Repository tragen.

Ich finde das beeindruckend und arbeite selbst intensiv damit. Ein Architekturproblem verschwindet dadurch allerdings nicht.

Klare Kontexte helfen nicht nur Menschen. Auch KI-Systeme arbeiten besser, wenn Module überschaubar sind, Verantwortungen explizit bleiben, Namen verständlich sind und Tests sowie Architekturregeln brauchbares Feedback liefern.

Ein schlecht geschnittenes System wird nicht automatisch einfacher, nur weil ein Agent mehr Dateien gleichzeitig verändern kann. Wenn alles mit allem verbunden ist, kann KI dieses Problem sogar schneller vervielfältigen.

Sind die Grenzen dagegen klar, wird der Arbeitsraum überschaubarer. Ein Agent kann Änderungen besser lokalisieren, vorhandene Patterns erkennen, Tests gezielter einsetzen und innerhalb eines begrenzten Kontextes arbeiten.

Deshalb halte ich gute Architektur im Zeitalter von Coding Agents nicht für weniger wichtig. Ich glaube nur, dass sich ein Teil ihrer Begründung verändert.

Sie ist nicht bloß etwas für Menschen, die professionelles Handwerk romantisieren und der guten alten Zeit nachtrauern. Klare Grenzen, explizites Wissen und überprüfbare Regeln machen auch agentisches Arbeiten zuverlässiger.

Warum ich darüber schreibe

Natürlich steckt auf dieser Seite auch Frust. Wer lange genug an Software arbeitet, sammelt davon zwangsläufig etwas.

Der wichtigere Grund ist aber ein anderer: Gute Softwareentwicklung macht mir Spaß.

Ich mag Systeme, die man erklären kann. Ich mag Code, der nicht bei jeder Änderung überrascht, Grenzen, die tatsächlich etwas schützen, und Teams, die dieselben Begriffe verwenden. Gute Tests geben einem die Möglichkeit, eine Änderung mit etwas mehr Mut und etwas weniger Gebet auszuliefern.

Architektur gefällt mir dann, wenn sie Veränderung ermöglicht, statt sie zu verhindern.

Ich schreibe diese Seite deshalb nicht, weil ich Frontends schlecht finde. Im Gegenteil. Ich mag Frontends, die Fachlichkeit ernst nehmen und nicht nur heute funktionieren. Systeme, die wachsen können, ohne bei jeder neuen Anforderung so zu reagieren, als wäre gerade zum ersten Mal jemand auf die Idee gekommen, dass Software sich verändern könnte.

Was diese Seite leisten soll

Diese Seite soll Muster sichtbar machen.

Ich möchte erklären, warum aus guten Absichten manchmal schlechte Systeme entstehen. Anti-Patterns sollen einen Namen bekommen, ohne dass daraus automatisch ein Urteil über die Menschen entsteht, die daran gearbeitet haben.

Architekturentscheidungen sollen vergleichbar werden. Mich interessiert, wo einfache Lösungen völlig ausreichen und wo vermeintliche Einfachheit nur bedeutet, dass ein Problem noch ein paar Monate ignoriert wird.

Nicht jede Situation braucht die perfekte Lösung. Manchmal ist ein sauberer Schnitt zu teuer. Manchmal kommt die Erkenntnis zu spät. Manchmal muss eine Brücke gebaut werden, damit ein bestehendes System überhaupt wieder veränderbar wird.

Nicht jedes Projekt braucht DDD. Nicht jedes Team braucht Microfrontends. Nicht jede Anwendung braucht einen Store und nicht jedes Problem verdient ein Framework.

Jedes System braucht aber ein Mindestmaß an Klarheit darüber, wo Verantwortung liegt, wie Daten fließen, wo Fachlichkeit lebt und welche Grenzen geschützt werden müssen.

Auch Abkürzungen sind völlig in Ordnung. Man sollte nur ungefähr wissen, welche davon später eine Rechnung schicken.

Was diese Seite nicht ist

Das hier ist kein Entwickler-Bashing.

Ein guter Architekt ist nicht automatisch der bessere Entwickler. Genauso wird aus einem hervorragenden Entwickler nicht automatisch ein guter Architekt. Das sind unterschiedliche Schwerpunkte.

Entwicklung verlangt technische Tiefe, Präzision und die Fähigkeit, gute Lösungen zu bauen. Architektur erweitert den Blick stärker auf Verantwortungen, Grenzen, Kopplung, Änderbarkeit, Risiken und die langfristigen Auswirkungen technischer Entscheidungen.

In guten Teams ergänzt sich das. Manchmal ist der stärkste Entwickler im Team nicht der Architekt. Das ist überhaupt kein Problem. Solche Kombinationen können ausgesprochen gut funktionieren, wenn beide Seiten ihre jeweiligen Stärken einbringen und einander ernst nehmen.

Diese Seite ist deshalb weder Tool-Review-Sammlung noch Framework-Kult. Sie ist auch keine Architektur-Folklore und kein „alles muss clean sein“-Theater.

Sie ist eine Sammlung aus Erfahrungen, Haltungen, Patterns, Anti-Patterns und Feldberichten aus echten Projekten. Manche Dinge habe ich früh verstanden, andere deutlich später. Einiges habe ich unter Druck gelernt und manches über ziemlich hässliche Zwischenlösungen.

Der Anspruch ist nicht, beim nächsten Mal alles richtig zu machen. Ein bisschen weniger naiv wäre schon ein guter Anfang.

Frontend-Architektur beginnt für mich deshalb auch nicht bei Ordnerstrukturen. Sie beginnt dort, wo Komponenten aufhören, alles zu wissen.