Wofür diese Seite steht

Weil gute Softwareentwicklung Spaß macht.

Nicht immer, nicht in jedem Projekt und nicht unter jedem Druck. Aber wenn ein System sauber geschnitten ist, Verantwortungen klar sind, Datenflüsse verständlich bleiben, Fachlichkeit einen Ort hat und Änderungen nicht wie ein Glücksspiel wirken, dann passiert etwas, das man in vielen Projekten fast vergessen kann:

Sie fühlt sich 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 wirklich gut ausüben kann.

Diese Seite existiert, weil ich genau dafür wieder mehr Raum schaffen möchte.

Woher ich komme

Ich komme nicht aus der Theorie.

Ich habe viele Jahre in regulierten Systemen gearbeitet. In Umgebungen, in denen Software nicht nur funktionieren muss, sondern nachvollziehbar, wartbar, prüfbar und verantwortbar bleiben soll.

Ich habe saubere Systeme über Jahre getragen: nicht nur gebaut und abgegeben, sondern weiterentwickelt, stabilisiert, erklärt, verteidigt und über viele Änderungen hinweg am Leben gehalten.

Ein gutes System erkennt man nicht am ersten Release. Man erkennt es nach drei, fünf oder sieben Jahren – wenn Menschen gegangen sind, Anforderungen sich verändert haben, regulatorische Vorgaben dazukommen, Teams wachsen und niemand mehr genau weiß, warum damals alles so entschieden wurde. Wenn das System dann trotzdem verständlich bleibt, zeigt sich seine Qualität.

Ich habe erlebt, wie viel Freude es machen kann, in einem solchen System zu arbeiten.

Und ich habe das Gegenteil erlebt.

Ich war in vielen Projekten der Feuerwehrmann, gerufen, wenn es schon brannte: wenn Änderungen Angst machten, Komponenten alles wussten, Services zu kleinen Betriebssystemen geworden waren, Stores alles machten, nur nichts richtig, und niemand mehr sagen konnte, wo Fachlichkeit lebt. Systeme, die zwar noch liefen, die aber niemand mehr wirklich zu verstehen behaupten wollte.

Diese Erfahrung prägt meinen Blick. Nicht, weil ich glaube, alles besser zu wissen, sondern weil man nach genug Bränden irgendwann beginnt, Brandschutz ernst zu nehmen.

Warum diese Seite?

Weil Frontend-Architektur zu oft entweder unterschätzt oder mystifiziert wird.

Für die einen ist es nur Frontend: ein bisschen UI, ein bisschen State, ein bisschen API, ein paar Komponenten. Wird schon.

Für die anderen ist Architektur etwas Abstraktes: Diagramme, Prinzipien, Buzzwords, Clean irgendwas, Konferenzfolien und schöne Begriffe für wenig Alltag.

Beides greift zu kurz.

Frontend-Architektur ist kein Selbstzweck und kein Schönheitswettbewerb. Sie ist die Summe der Entscheidungen, die dafür sorgen, dass ein System auch morgen noch verstanden, geändert und verantwortet werden kann.

Sie entscheidet, ob ein Team schnell bleibt oder nur am Anfang schnell wirkt. Ob Fachlichkeit sichtbar bleibt oder in Komponenten, Services und Stores versickert. Ob neue Anforderungen integriert oder hineingestopft werden. Ob ein System wächst – oder nur anschwillt.

Diese Seite ist mein Versuch, darüber konkret zu schreiben: nicht neutral, nicht weichgespült und nicht als Framework-Marketing, sondern aus der Perspektive von jemandem, der saubere Systeme getragen und brennende Systeme gelöscht hat.

Was mich vom Rest unterscheidet

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

Ich möchte über die Stellen schreiben, an denen Architektur im echten Projektalltag scheitert oder trägt: über Komponenten, die plötzlich Use Cases spielen; Services, die Verantwortung sammeln wie Staub; Stores, die Seiteneffekte, Business-Logik und ViewModels vermischen; reaktive Datenflüsse, die durch imperative Abkürzungen brechen; Microfrontends, die keine Grenzen lösen, sondern fehlende Grenzen verteilen; regulierte Systeme, in denen Nachvollziehbarkeit nicht optional ist; und Teams, die Qualität wollen, aber keine Zeit bekommen, die Axt zu schärfen.

Aber genauso über das Gegenteil: klare Schnitte, gute Namen, kleine verständliche Kontexte, vertikale Architektur, fachliche Sprache, Tests, die Vertrauen schaffen, Stores, die wirklich helfen, Schnittstellen, die nicht alles verraten, und Brücken, die Legacy nicht schönreden, aber veränderbar machen.

Ich will nicht nur sagen, was schlecht ist. Ich will zeigen, warum es passiert, woran man es erkennt und wie man wieder herauskommt.

Architektur ist Handwerk

Viele Menschen tun so, als wäre Softwareentwicklung Magie.

Ist sie nicht.

Große Teile davon sind Handwerk: saubere Schnitte, klare Begriffe, wiederholbare Entscheidungen, gute Werkzeuge, Übung, Disziplin, Feedback, Mentoring, Erfahrung – und die Demut, nicht jedes Problem mit Genialität erschlagen zu wollen.

Architektur ist in diesem Sinne kein Elfenbeinturm. Sie ist handwerkliche Verantwortung auf Systemebene.

Sie fragt nicht nur: Wie bekomme ich dieses Feature fertig?

Sondern auch: Wo gehört diese Verantwortung hin? Was passiert bei der nächsten Änderung? Wie bleibt der Datenfluss verständlich? Welche Abhängigkeit entsteht hier? Welche Entscheidung wird später schwer rückgängig zu machen? Wer muss diesen Code in zwei Jahren noch verstehen?

Das ist nicht langsam.

Das ist professionell.

Warum das mit KI noch wichtiger wird

KI-Tooling verändert Softwareentwicklung.

Code wird schneller erzeugt, Varianten werden billiger und Prototypen entstehen in Minuten. Agenten können Aufgaben übernehmen, Dateien ändern, Tests schreiben, Vorschläge machen und große Mengen Code bewegen.

Das ist beeindruckend. Aber es löst kein Architekturproblem automatisch.

Im Gegenteil.

KI funktioniert besser in klaren Kontexten: mit kleinen Modulen, expliziten Grenzen, eindeutigen Verantwortungen, sauberen Namen, guten Tests, verständlichen Datenflüssen, klaren Architekturregeln und dokumentierten Entscheidungen.

Das sind nicht nur klassische Qualitätsmerkmale. Sie sind Voraussetzungen dafür, dass KI-gestützte Entwicklung nicht einfach nur schneller Chaos produziert.

Ein schlecht geschnittenes System ist nicht deshalb leichter zu ändern, weil ein Agent mehr Dateien anfassen kann. Wenn alles mit allem verdrahtet ist, wird auch KI vorsichtig, ungenau oder gefährlich.

Sind Kontexte dagegen klein und Grenzen klar, kann KI viel besser helfen. Sie kann Änderungen lokalisieren, Tests gezielter erzeugen, Patterns wiederverwenden, Regeln einhalten, Zusammenhänge erklären und innerhalb eines begrenzten Raums sinnvoll arbeiten.

Saubere Architektur ist damit nicht weniger wichtig.

Sie wird wichtiger.

Nicht als Nostalgie professioneller Handwerker, die Angst vor KI haben, sondern als Grundlage dafür, dass KI-Tooling überhaupt zuverlässig nutzbar wird.

Nicht Frust. Motivation.

Natürlich steckt in dieser Seite Frust. Wer lange genug in Softwareprojekten arbeitet, sammelt ihn automatisch.

Aber Frust ist nicht der Kern.

Der Kern ist Freude an guter Softwareentwicklung: an Systemen, die man erklären kann; an Code, der nicht überrascht; an Grenzen, die schützen; an Teams, die dieselbe Sprache sprechen; an Tests, die Mut machen; und an Architektur, die nicht im Weg steht, sondern Veränderung ermöglicht.

Ich schreibe diese Seite nicht, weil ich Frontends hasse.

Ich schreibe sie, weil ich gute Frontends mag.

Frontends, die Fachlichkeit ernst nehmen, die nicht nur funktionieren, sondern tragfähig sind und die nicht bei jeder Änderung so tun, als wäre gerade zum ersten Mal jemand auf die Idee gekommen, dass Software wachsen könnte.

Was diese Seite leisten soll

Diese Seite soll Muster sichtbar machen.

Sie soll erklären, warum gute Absichten oft schlechte Systeme erzeugen, Anti-Patterns benennen, ohne Menschen pauschal abzuwerten, und Mythen aufräumen, ohne neue Dogmen zu bauen. Sie soll Architekturentscheidungen vergleichbar machen, zeigen, wo einfache Lösungen reichen und wo Einfachheit nur noch Verdrängung ist, und Brücken sichtbar machen, wenn ein perfekter Schnitt zu teuer, zu spät oder unrealistisch ist.

Nicht jedes Projekt braucht DDD. Nicht jedes Team braucht Microfrontends. Nicht jede App braucht einen Store. Nicht jedes Problem verdient ein Framework.

Aber jedes System braucht Klarheit darüber, wo Verantwortung liegt, wie Daten fließen, wo Fachlichkeit lebt, welche Grenzen geschützt werden müssen und welche Abkürzung später zur Rechnung wird.

Was diese Seite nicht ist

Das hier ist kein Entwickler-Bashing.

Gute Entwickler sind wertvoll. Gute Senior Developer erst recht.

Aber ein guter Entwickler ist nicht automatisch ein Architekt. Nicht, weil er zu wenig kann, sondern weil Architektur einen anderen Blickwinkel verlangt.

Ein Entwickler baut Lösungen. Ein Architekt fragt zusätzlich, ob das Problem richtig geschnitten ist.

Ein Entwickler sieht Codequalität. Ein Architekt sieht zusätzlich Änderbarkeit, Kopplung, Verantwortung, Risiken, Grenzen und die langfristigen Kosten von Entscheidungen.

Beides wird gebraucht.

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

Sie ist eine Sammlung von Haltungen, Patterns, Anti-Patterns und Feldberichten aus echten Projekten. Manches davon habe ich zu spät gelernt, manches unter Druck, manches mit hässlichen Brücken – aber immer mit dem Anspruch, beim nächsten Mal weniger naiv zu sein.

Frontend-Architektur beginnt nicht bei Ordnerstrukturen.

Sie beginnt dort, wo Komponenten aufhören, alles zu wissen.