Warum?

Weil gute Softwareentwicklung Spaß macht.

Nicht immer. Nicht in jedem Projekt. Nicht unter jedem Druck. Nicht in jedem System.

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

Sie fühlt sich wieder nach Handwerk an.

Nicht nach Magie.
Nicht nach Heldentum.
Nicht nach 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 Jahren.
Nach fünf Jahren.
Nach sieben Jahren.
Wenn Menschen gegangen sind.
Wenn Anforderungen sich geändert haben.
Wenn regulatorische Vorgaben dazukommen.
Wenn Teams wachsen.
Wenn niemand mehr genau weiß, warum damals alles so entschieden wurde — und das System trotzdem noch verständlich bleibt.

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.
Wenn Komponenten alles wussten.
Wenn Services zu kleinen Betriebssystemen geworden waren.
Wenn Stores alles machten, nur nichts richtig.
Wenn niemand mehr sagen konnte, wo Fachlichkeit lebt.
Wenn das System zwar noch lief, aber niemand mehr behaupten wollte, es wirklich zu verstehen.

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.
Schöne Begriffe für wenig Alltag.

Beides greift zu kurz.

Frontend-Architektur ist kein Selbstzweck.
Sie ist auch 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.
Sie entscheidet, ob Fachlichkeit sichtbar bleibt oder in Komponenten, Services und Stores versickert.
Sie entscheidet, ob neue Anforderungen integriert oder hineingestopft werden.
Sie entscheidet, ob ein System wächst — oder nur anschwillt.

Diese Seite ist mein Versuch, darüber konkret zu schreiben.

Nicht neutral.
Nicht weichgespült.
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.
Über Services, die Verantwortung sammeln wie Staub.
Über Stores, die Seiteneffekte, Business-Logik und ViewModels vermischen.
Über reaktive Datenflüsse, die durch imperative Abkürzungen brechen.
Über Microfrontends, die keine Grenzen lösen, sondern fehlende Grenzen verteilen.
Über regulierte Systeme, in denen Nachvollziehbarkeit nicht optional ist.
Über Teams, die Qualität wollen, aber keine Zeit bekommen, die Axt zu schärfen.

Aber auch über das Gegenteil:

Über klare Schnitte.
Über gute Namen.
Über kleine, verständliche Kontexte.
Über vertikale Architektur.
Über fachliche Sprache.
Über Tests, die Vertrauen schaffen.
Über Stores, die wirklich helfen.
Über Schnittstellen, die nicht alles verraten.
Über 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.
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.

Kleine Module.
Explizite Grenzen.
Eindeutige Verantwortungen.
Saubere Namen.
Gute Tests.
Verständliche Datenflüsse.
Klare Architekturregeln.
Dokumentierte Entscheidungen.

Das sind nicht nur klassische Qualitätsmerkmale.

Das 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.

Wenn Kontexte klein und Grenzen klar sind, kann KI viel besser helfen:

Sie kann Änderungen lokalisieren.
Sie kann Tests gezielter erzeugen.
Sie kann Patterns wiederverwenden.
Sie kann Regeln einhalten.
Sie kann Zusammenhänge erklären.
Sie kann in einem begrenzten Raum 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.
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.
Frontends, die nicht nur funktionieren, sondern tragfähig sind.
Frontends, die nicht bei jeder Änderung so tun, als wäre gerade das erste 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.
Sie soll Anti-Patterns benennen, ohne Menschen pauschal abzuwerten.
Sie soll Mythen aufräumen, ohne neue Dogmen zu bauen.
Sie soll Architekturentscheidungen vergleichbar machen.
Sie soll zeigen, wo einfache Lösungen reichen und wo Einfachheit nur noch Verdrängung ist.
Sie soll Brücken zeigen, 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 Ä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.
Kein „alles muss clean sein”-Theater.

Sie ist eine Sammlung von Haltungen, Patterns, Anti-Patterns und Feldberichten aus echten Projekten.

Manchmal zu spät gelernt.
Manchmal unter Druck.
Manchmal 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.