Martin Fowlers Ansatz: Architektur, die trendige Stacks überdauert

Warum angesagte Tech‑Stacks keine gute Architektur garantieren

Ein neues Framework, ein glänzender Cloud‑Dienst oder der „Standard‑Stack“ in einem angesagten Unternehmen kann wie eine Abkürzung zur Qualität wirken. Aber Stack‑zuerst‑Denken verwechselt oft Werkzeuge mit Struktur. Du kannst ein chaotisches, schwer veränderbares System mit den modernsten Technologien bauen — oder ein sauberes, anpassungsfähiges mit langweiligen, gut bekannten Entscheidungen.

Das Problem mit „Stack‑zuerst“‑Denken

Die Wahl des Stacks zuerst drängt Teams zu Entscheidungen, die auf einer Folie beeindruckend aussehen, aber die wirklichen Fragen nicht beantworten:

• Wo liegen die Grenzen?
• Was muss sich oft ändern?
• Was muss stabil bleiben?

Wenn die Technologieauswahl führt, wird Architektur zum zufälligen Nebenprodukt — mit enger Kopplung, duplizierter Logik und Abhängigkeiten, die einfache Änderungen teuer machen.

Deshalb ist „wir nutzen Microservices“ (oder „wir sind jetzt serverless“) keine Architektur. Das ist eine Deploy‑ und Tooling‑Richtung. Architektur beschreibt, wie Teile des Systems zusammenarbeiten, wie Entscheidungen künftige Arbeit einschränken und wie leicht das Produkt sich entwickeln lässt.

Eine praktische Konsequenz: Werkzeuge können die Lieferung beschleunigen, ersetzen aber kein architektonisches Denken. Selbst mit modernen „vibe‑coding“‑Ansätzen — wo man schnell per Chat generiert und iteriert — bleiben dieselben Fragen relevant. Plattformen wie Koder.ai können den Bau von Web‑, Backend‑ und Mobile‑Apps stark beschleunigen, aber die Teams mit den besten Ergebnissen behandeln Grenzen, Ownership und Änderbarkeit weiterhin als erstklassige Anliegen (nicht als Dinge, die das Framework magisch löst).

Fowlers Einfluss: Klarheit, Pragmatismus und Wandel über Zeit

Martin Fowlers Schriften lenken konstant zurück auf das, was zählt: klares Design statt modischer Komponenten, praktische Abwägungen statt Ideologie und die Fähigkeit, das System beim Lernen weiterzuentwickeln. Seine Arbeit sieht Architektur als etwas, das kontinuierlich verbessert wird — nicht als einmalige „Big Design“‑Etappe.

Worum es in diesem Artikel geht

Erwarte drei wiederkehrende Themen: Muster als optionale Werkzeuge (nicht als Gebote), Refactoring als regelmäßige Gewohnheit und evolutionäre Architektur — für Veränderung bauen, nicht für Gewissheit.

Für wen das ist

Wenn du Engineering‑Leader, Tech‑Lead oder ein Produktteam bist, das schneller ausliefern will, ohne dass die Qualität zusammenbricht, ist das für dich. Ziel ist nicht, den „perfekten“ Stack zu wählen, sondern Entscheidungen zu treffen, die die Software änderbar halten, wenn die Roadmap sich unvermeidlich verschiebt.

Was „Softwarearchitektur" wirklich bedeutet (ohne Jargon)

Softwarearchitektur ist die Menge an Entscheidungen, die ein System so formen, dass sie später schwer (und teuer) zu ändern sind.

Diese Definition ist bewusst einfach. Sie braucht keine speziellen Diagramme oder einen Titel wie „Architect“. Es geht um die Entscheidungen, die bestimmen, wie die Software wachsen kann, wie Teams daran arbeiten und was der Betrieb kosten wird.

Architektur ist nicht dein Tech‑Stack

Frameworks, Tools und Coding‑Style sind wichtig — aber die meisten sind leicht austauschbar im Vergleich zu echten Architekturentscheidungen.

• Die Wahl zwischen React und Vue ist oft reversibel.
• Die Entscheidung, dass „alle Schreibzugriffe durch einen einzigen Service laufen müssen“, ist viel schwerer rückgängig zu machen.

Architektur steht näher an Struktur und Grenzen: wie Systemteile kommunizieren, wo Daten leben, wie Fehler gehandhabt werden und welche Änderungen Team‑Koordination erfordern.

Architektur ist meist ein Bündel von Kompromissen

Es gibt keine universell „beste“ Architektur. Jede größere Entscheidung optimiert für einige Ziele und belastet andere:

• Performance vs. Einfachheit: Caching‑Schichten können beschleunigen, fügen aber Komplexität und knifflige Randfälle hinzu.
• Team‑Tempo vs. Zuverlässigkeit: Schnelle Releases unterstützen Lernen, benötigen aber stärkere Tests und Rollout‑Praktiken.
• Kosten vs. Resilienz: Redundanz verbessert Uptime, erhöht aber Infrastruktur‑ und Wartungskosten.

Gute Architektur macht diese Kompromisse explizit statt zufällig.

Ein kurzes Beispiel: Architekturentscheidung vs. Bibliothekswahl

• Architekturentscheidung: „Wir trennen das Kunden‑Billing in einen eigenen deploybaren Service mit eigener Datenbank; der Rest integriert über asynchrone Events."

  Das beeinflusst Deployment, Datenverantwortung, Fehlermodi, Monitoring und Teamkoordination.

• Bibliothekswahl: „Wir verwenden Bibliothek X zum Erzeugen von PDFs."

  Nützlich, aber meist mit begrenzter Blast‑Radius ersetzbar.

Wenn das Zurückdrehen einer Entscheidung Wochen koordinierten Aufwands erfordert, ist es wahrscheinlich Architektur.

Muster als Werkzeuge: Nützlich, optional und manchmal fehlgenutzt

Designmuster sind am besten als wiederverwendbare Lösungen für wiederkehrende Probleme zu verstehen, nicht als Gebote. Fowlers Haltung ist pragmatisch: Muster sind nützlich, wenn sie das Design klären, und schädlich, wenn sie das Denken ersetzen.

Wann Muster helfen

Richtig eingesetzt geben Muster Teams eine gemeinsame Sprache. „Strategy“ oder „Repository“ zu sagen, kann eine lange Erklärung auf ein Wort komprimieren, wodurch Reviews schneller werden und Missverständnisse seltener.

Muster machen das Systemverhalten auch vorhersehbarer. Ein vertrautes Muster setzt Erwartungen darüber, wo Logik liegt, wie Objekte zusammenarbeiten und welche Änderungen wahrscheinlich durchschlagen. Diese Vorhersehbarkeit reduziert Überraschungen in Produktion und die Frage „Wie funktioniert das überhaupt?“ für neue Teammitglieder.

Wann Muster schaden

Die Fehlfunktion ist Cargo‑Kult: ein Muster anwenden, weil es populär ist, weil ein Buch es listet oder weil „wir das hier so machen“. Das führt oft zu Over‑Engineering — zusätzliche Schichten, Indirektion und Abstraktionen, die nichts einbringen.

Eine weitere Falle ist „ein Muster für alles“. Wenn jedes kleine Problem eine benannte Lösung bekommt, verwandelt sich der Code in ein Museum von Cleverness statt in ein Werkzeug zum Liefern und Warten.

Eine praktische Auswahlmethode

Fange mit dem Problem an, nicht mit dem Muster.

Frage:

• Welche Änderung wollen wir erleichtern?
• Welches Risiko reduzieren wir?
• Welche Komplexität führen wir ein?

Dann wähle das einfachste Muster, das passt und Optionen offenhält. Wenn das Design später mehr Struktur braucht, kannst du sie inkrementell einführen — oft geleitet von echtem Schmerz und bestätigt durch Refactoring, statt im Vorfeld zu raten.

Refactoring: Die Gewohnheit, die Architektur gesund hält

Refactoring ist die Praxis, das interne Design der Software zu verbessern ohne ihr Verhalten zu ändern. Nutzer sollten nach einem Refactor nichts anderes bemerken — außer dass künftige Änderungen leichter, sicherer und schneller werden.

Fowlers Punkt ist nicht „haltet euren Code hübsch“. Es ist, dass Architektur kein einmaliges Diagramm am Anfang ist. Architektur sind die Entscheidungen, die bestimmen, wie leicht sich das System ändern lässt. Refactoring verhindert, dass diese Entscheidungen zu starren Beschränkungen werden.

Warum Refactoring eine architektonische Tätigkeit ist

Im Lauf der Zeit driftet selbst gut gestaltete Software ab. Neue Features werden unter Zeitdruck hinzugefügt, Schnelllösungen werden permanent und Grenzen verschwimmen. Refactoring stellt klare Trennung wieder her und reduziert zufällige Komplexität, damit das System änderbar bleibt.

Eine gesunde Architektur ist eine, in der:

• wichtige Geschäftsregeln nicht mit UI‑Details verknotet sind
• Module klare Verantwortlichkeiten haben
• Abhängigkeiten in sinnvolle Richtungen zeigen

Refactoring ist die tägliche Arbeit, die diese Eigenschaften bewahrt.

Übliche Auslöser: „Jetzt ist es Zeit“

Refactoring plant man selten wegen eines Kalendereintrags. Man macht es, weil der Code anfängt, sich zu wehren:

• Duplikation: dieselbe Regel an drei Stellen, die langsam auseinanderlaufen
• Unklare Grenzen: „alles berührt alles“, Änderungen werden riskant
• Langsame Lieferung: einfache Anforderungen brauchen Tage, weil jede Änderung Überraschungen bringt

Wenn das auftritt, ist die Architektur bereits betroffen — Refactoring ist die Reparatur.

Wie man sicher refaktoriert (ohne Dinge zu brechen)

Sicheres Refactoring beruht auf ein paar Gewohnheiten:

• Tests, die unbeabsichtigte Verhaltensänderungen auffangen (besonders für Kern‑Business‑Logik)
• Kleine Schritte: viele winzige, reversible Änderungen statt eines großen Rewrites
• Code‑Reviews: eine zweite Sicht, die Nebenwirkungen und Scope‑Creep erkennt

So wird Refactoring zur routinemäßigen Wartung — das System bleibt bereit für die nächste Änderung statt fragil nach der letzten.

Technische Schulden: Wie sie sich anhäufen und wie man sie abzahlt

Technische Schulden sind die zukünftigen Kosten, die durch heutige Abkürzungen entstehen. Es ist kein moralisches Versagen schlechten Codes; es ist ein Trade‑off, den man (manchmal bewusst) eingeht und der die Änderungskosten später erhöht. Fowlers Betrachtung ist nützlich: Schulden sind nur dann ein Problem, wenn man aufhört, sie zu verfolgen und so tut, als wären sie nicht da.

Vorsätzliche vs. unabsichtliche Schulden

Vorsätzliche Schulden nimmt man mit offenen Augen auf: „Wir liefern jetzt die einfache Version und härten sie im nächsten Sprint nach.“ Das kann rational sein — wenn man auch die Rückzahlung plant.

Unabsichtliche Schulden entstehen, wenn das Team nicht merkt, dass es sich verschuldet: chaotische Abhängigkeiten schleicht sich ein, ein unklarer Domain‑Modell breitet sich aus oder eine Schnelllösung wird Standard. Unabsichtliche Schulden sind oft teurer, weil niemand deren Eigentümer ist.

Wie Schulden stillschweigend wachsen

Schulden häufen sich durch normalen Druck:

• Gedrückte Deadlines, die zu „einfach soll es funktionieren“‑Entscheidungen zwingen
• Unklare Ownership, sodass sich niemand für die Gesundheit eines Moduls verantwortlich fühlt
• Fehlende oder fragile Tests, die Änderungen furchteinflößend machen und zu weiteren Abkürzungen verleiten

Das Resultat ist vorhersehbar: Features werden langsamer, Bugs nehmen zu und Refactoring wirkt riskant statt routiniert.

Leichte Wege, Schulden zu verwalten und abzuzahlen

Man braucht kein großes Programm, um Schulden zu tilgen:

• Budgetiere kontinuierlich Zeit (z. B. ein kleiner Anteil jeder Iteration)
• Tracke Hotspots, nicht alles: konzentriere dich auf Code, den du oft anfasst und vor dem du dich fürchtest
• Zahle in kleinen Schritten zurück: kombiniere Refactoring mit Feature‑Arbeit, damit die „Zinsen“ aufhören zu wachsen

Wenn du Schuldenentscheidungen sichtbar machst (siehe /blog/architecture-decision-records), verwandelst du versteckte Kosten in handhabbare Arbeit.

Evolutionäre Architektur: Für Veränderung bauen, nicht für Gewissheit

Softwarearchitektur ist kein Bauplan, den man einmal „richtig“ zeichnet. Fowlers Sicht fördert eine praktischere Idee: Gehe davon aus, dass Anforderungen, Traffic, Teams und Restriktionen sich verschieben — und designe so, dass das System sich ohne schmerzhafte Rewrites anpassen kann.

Was „evolutionäre Architektur" bedeutet

Evolutionäre Architektur heißt: für Veränderung entwerfen, nicht für Perfektion. Anstatt auf eine langfristige Vorhersage zu setzen („wir brauchen Microservices“, „wir skalieren 100x“), baust du eine Architektur, die sicher evolvieren kann: klare Grenzen, automatisierte Tests und Deploy‑Praktiken, die häufige, risikoarme Anpassungen erlauben.

Kleine Releases, echtes Feedback

Pläne sind Vermutungen; Produktion ist Realität. Kleine Inkremente ausliefern hilft zu lernen, was Nutzer wirklich tun, was der Betrieb wirklich kostet und wo Performance oder Zuverlässigkeit wirklich zählt.

Kleine Releases verändern auch den Entscheidungsstil: Du kannst eine moderate Verbesserung versuchen (z. B. ein Modul trennen oder eine neue API‑Version einführen) und messen, ob sie geholfen hat — statt dich auf eine massive Migration festzulegen.

Hier können schnelle Iterationstools helfen — solange du architektonische Leitplanken beibehältst. Wenn du z. B. eine Plattform wie Koder.ai nutzt, um Features schnell zu generieren und zu iterieren, dann hilft diese Geschwindigkeit nur, wenn modulare Grenzen, gute Tests und häufige Deploys bestehen; sonst „schnell liefern“ in eine Sackgasse.

Fitness‑Funktionen (einfach erklärt)

Eine zentrale Idee der Evolution sind „Fitness‑Funktionen": eine messbare Prüfung, die ein architektonisches Ziel schützt. Stell sie dir als Leitplanke vor. Läuft diese Prüfung automatisiert und kontinuierlich, kannst du mit Vertrauen ändern, weil die Leitplanken dich warnen, wenn du abdriftest.

Fitness‑Funktionen müssen nicht kompliziert sein. Es können einfache Metriken, Tests oder Schwellenwerte sein, die widerspiegeln, was dir wichtig ist.

Beispiele für praktische Fitness‑Checks

• Build‑Zeit: Pipeline schlägt fehl, wenn Build/Test‑Zyklus ein Budget (z. B. 10 Minuten) überschreitet. Langsame Builds hemmen Refactoring.
• Fehlerrate: Alarm oder Blockierung eines Rollouts, wenn die Produktionsfehlerrate über einen definierten Basiswert steigt.
• Security‑Scanning: Abhängigkeiten und Container automatisch scannen; Builds bei bekannten kritischen Verwundbarkeiten fehlschlagen lassen.
• API‑Kompatibilität: Vertragstests, um sicherzustellen, dass neue Releases bestehende Clients oder interne Konsumenten nicht brechen.

Der Punkt ist nicht, alles zu messen. Wähle eine Handvoll Checks, die deine architektonischen Versprechen widerspiegeln — Änderungs‑Geschwindigkeit, Zuverlässigkeit, Sicherheit und Interoperabilität — und lass diese Checks den Alltag steuern.

Microservices vs. Monolithen: Nach Constraints wählen, nicht nach Mode

Microservices sind kein Qualitätsabzeichen. Fowlers Punkt ist einfacher: Das Splitten in Services ist ebenso eine organisatorische wie eine technische Entscheidung. Wenn deine Teams Services nicht ende‑zu‑ende besitzen (bauen, deployen, betreiben, weiterentwickeln), bekommst du die Komplexität ohne die Vorteile.

Drei Formen, drei Kompromisse

Ein Monolith ist eine deploybare Einheit. Das kann eine Stärke sein: weniger bewegliche Teile, einfacheres Debugging und unkomplizierte Datenkonsistenz. Die Kehrseite tritt auf, wenn der Code verfilzt — kleine Änderungen erfordern große Koordination.

Ein modularer Monolith ist weiterhin eine deploybare Einheit, aber der Code ist bewusst in klare Module mit durchgesetzten Grenzen aufgeteilt. Du behältst die operative Einfachheit eines Monolithen und reduzierst gleichzeitig interne Kopplung. Für viele Teams ist das die beste Default‑Wahl.

Microservices geben jedem Service eigenes Deployment und Lifecycle. Das kann unabhängige Releases und klare Ownership ermöglichen — wenn die Organisation bereit ist. Andernfalls verwandelt es oft „ein hartes Problem“ in „zehn harte Probleme".

Versteckte Kosten, die man vergisst

Microservices fügen Overhead hinzu, der nicht im Architekturdiagramm sichtbar ist:

• Deployments: mehr Pipelines, Versionierung, Rollbacks und Koordination
• Observability: Distributed Tracing, Log‑Korrelation und sinnvolle Metriken
• On‑Call‑Last: mehr Fehlermodi, mehr Alerts, mehr Incident‑Playbooks
• Datenkonsistenz: schwierigere Transaktionen, Eventual Consistency und komplizierte Reports

Eine praktische Heuristik

Starte mit einem modularen Monolithen. Miss echten Druck, bevor du splittest: Release‑Bottlenecks, Team‑Kontention um ein Modul, Skalierungs‑Hotspots oder Bedürfnisse nach Reliability‑Isolation. Wenn diese Belastungen persistent und quantifiziert sind, löse ein Service mit klarer Grenze, eigener Ownership und einem Betriebsplan — nicht nur Code.

Grenzen, Kopplung und die wahren Kosten von Abhängigkeiten

Gute Architektur hängt nicht von der Anzahl der Services ab; sie hängt davon ab, wie gut du einen Teil ändern kannst, ohne drei andere kaputtzumachen. Fowler stellt das oft als Management von Kopplung (wie verknüpft Teile sind) und Kohäsion (wie gut ein Teil „zusammenhängt") dar.

Kopplung und Kohäsion, ohne Jargon

Denk an eine Restaurantküche. Eine kohäsive Station (z. B. „Salate") hat alles, was sie braucht — Zutaten, Werkzeuge und eine klare Verantwortung. Eine eng gekoppelte Küche bedeutet, dass das Salatmachen den Grillkoch aufhält, der Konditor das Dressing freigeben muss und der Manager die Kühlung freischaltet.

Software funktioniert genauso: kohäsive Module besitzen eine klare Aufgabe; lose gekoppelte Module interagieren über einfache, stabile Vereinbarungen.

Wie man ungesunde Kopplung erkennt

Ungesunde Kopplung zeigt sich oft im Zeitplan, bevor sie im Code sichtbar wird. Signale:

• Koordinierte Releases: „Wir können nicht ausliefern, bis Team B liefert."
• Häufige teamübergreifende Blocker: Arbeiten stoppen, weil ein anderes Team zuerst etwas ändern muss.
• Kettenreaktionen: Ein kleines Feature erfordert Änderungen in vielen Repos/Services.

Wenn dein Delivery‑Prozess regelmäßig Gruppenchoreographie braucht, wird der Abhängigkeitspreis bereits bezahlt — nur in Meetings und Verzögerungen.

Design‑Schritte zur Reduktion von Kopplung

Kopplung reduzieren erfordert keinen Rewrite. Praktische Schritte:

• Klare APIs und Verträge: Behandle die Schnittstelle wie ein Produkt; halte sie stabil und gut benannt.
• Bounded Contexts: Entscheide, was jeder Bereich besitzt, inklusive Regeln und Vokabular.
• Modularisierung: Selbst im Monolithen können Module mit expliziten Grenzen wie Mini‑Services arbeiten, ohne operativen Overhead.

Wenn Entscheidungen wichtig sind, halte sie mit leichten Notizen fest, z. B. [/blog/architecture-decision-records], damit Grenzen bewusst bleiben.

Daten: die schwierigste Grenze

Geteilte Datenbanken erzeugen „geheime“ Kopplung: Jedes Team kann eine Tabelle ändern und versehentlich alle anderen brechen. Eine geteilte DB zwingt oft zu koordinierten Releases, selbst wenn Services unabhängig erscheinen.

Gesünder ist Datenverantwortung: Ein System besitzt ein Datenset und bietet es über eine API oder Events an. So werden Abhängigkeiten sichtbar — und damit handhabbar.

Architektur ist auch sozial: Teams formen Systeme

Softwarearchitektur ist nicht nur Kästchen und Pfeile. Es geht auch um Menschen: wie Arbeit geteilt wird, wie Entscheidungen fallen und wie schnell ein Team reagiert, wenn die Realität vom Design abweicht. Das ist sozio‑technische Architektur — die Idee, dass die Struktur deines Systems tendenziell die Struktur deiner Organisation widerspiegelt.

Wenn das Organigramm dem Design widerspricht

Ein typisches Scheitern ist, auf dem Papier saubere Grenzen zu entwerfen, während der Alltag sie durchbricht. Das System kompiliert und deployt vielleicht, fühlt sich aber teuer in der Änderung an.

Muster:

• Häufige Handoffs („Team A muss genehmigen, dann deployt Team B, dann überwacht Team C")
• Unklare Ownership („Wer ist für diesen Endpoint verantwortlich?“ „Nicht wir.")
• Langsame Incident‑Reaktion, weil Alerts, Logs und Fixes mehrere Teams überqueren
• Roadmaps, die koordinierte Releases vieler Gruppen verlangen

Praktische Wege, Reibung zu reduzieren

Fange mit Ownership an, nicht mit Perfektion. Ziele Grenzen, die zu den realen Arbeitsweisen deiner Teams passen.

• Module/Services an Teams ausrichten: Ein Team sollte eine sinnvolle Änderung vornehmen können, ohne mit fünf anderen zu koordinieren.
• Verantwortung klären: Definiere, wer baut, betreibt und verbessert (inkl. On‑Call und Betriebsbudget).
• Handoffs begrenzen: Bevorzuge Schnittstellen, die Teams unabhängig bewegen lassen — stabile Kontrakte, gut definierte APIs und gemeinsame Standards, wenn sie helfen.

Realistisch bleiben bei Einschränkungen

Manchmal kannst du nicht umorganisieren, ein Legacy‑Modul nicht splitten oder nicht schnell genug Leute einstellen. Dann betrachte Architektur als Verhandlung: wähle Grenzen, die die kostspieligste Koordination reduzieren, investiere in Refactoring, das Autonomie freisetzt, und akzeptiere Übergangslösungen, während du technische und organisatorische Schulden abzahlst.

Entscheidungen sichtbar machen: einfache Architecture Decision Records

Softwarearchitektur ist nicht nur, was du baust — es sind auch die Entscheidungen, die du triffst. Architecture Decision Records (ADRs) sind kurze Notizen, die diese Entscheidungen festhalten, solange der Kontext noch frisch ist.

Was ein ADR ist (und was nicht)

Ein ADR ist ein einseitiges Memo, das beantwortet: „Was haben wir entschieden und warum?“ Es ist kein langes Designpapier und kein Genehmigungsformular. Denk an es als dauerhaftes Gedächtnis für das Team.

Was rein sollte

Halte die Struktur konsistent, damit man schnell scannen kann. Ein leichtgewichtiges ADR enthält üblicherweise:

• Entscheidung: was gewählt wurde (z. B. „Modularer Monolith für v1").
• Kontext: welches Problem gelöst werden soll und welche Beschränkungen bestanden.
• Alternativen: 2–3 realistische Optionen.
• Konsequenzen: die Trade‑offs — was einfacher, was schwerer wird.
• Datum und Status: vorgeschlagen/akzeptiert/ersetzt.
• Owner: wer die Entscheidung vorangetrieben hat (nicht „wer zu beschuldigen“).

Warum es sich auszahlt

ADRs beschleunigen Onboarding, weil neue Teammitglieder der Begründung folgen können, nicht nur dem Endergebnis. Sie verhindern wiederholte Debatten: Wenn dieselbe Frage Monate später wieder aufkommt, kannst du das ADR prüfen und aktualisieren statt von vorne zu verhandeln. Vor allem machen ADRs Trade‑offs explizit — nützlich, wenn sich die Realität ändert und du den Plan revidieren musst.

Leicht bleiben

Verwende eine einfache Vorlage, speichere ADRs neben dem Code (z. B. in /docs/adr/) und plane 10–20 Minuten, um eins zu schreiben.

# ADR 012: API versioning strategy
Date: 2025-12-26
Status: Accepted
Owners: Platform team

Context:
We need to evolve public APIs without breaking partners.

Decision:
Adopt URL-based versioning (/v1/, /v2/).

Alternatives:
- Header-based versioning
- No versioning; rely on backward compatibility

Consequences:
+ Clear routing and documentation
- More endpoints to support over time

Wenn ein ADR sich wie Bürokratie anfühlt, kürze ihn — gib die Gewohnheit nicht auf.

Continuous Delivery und Feedback: Der Motor der Evolution

Architektur bleibt nicht „gut“, weil jemand einmal ein sauberes Diagramm zeichnete. Sie bleibt gut, wenn das System sich sicher in kleinen Schritten unter realem Druck ändern kann. Deshalb sind Continuous Delivery (CD) und schnelle Feedback‑Schleifen so wichtig: sie machen Evolution zur normalen Gewohnheit statt zum riskanten Ereignis.

CI/CD macht Refactoring praktisch

Refactoring ist am einfachsten, wenn Änderungen klein und reversibel sind. Eine gesunde CI/CD‑Pipeline unterstützt das, indem sie jede Änderung automatisch baut, testet und validiert, bevor sie Nutzer erreicht. Wenn die Pipeline vertrauenswürdig ist, können Teams Design kontinuierlich verbessern statt auf einen „großen Rewrite“ zu warten, der nie geliefert wird.

Qualitätsgates, die Veränderung ermöglichen (nicht Bürokratie)

Qualitätsgates sollten schnell, konsistent und an Ergebnissen orientiert sein. Übliche Gates:

• Automatisierte Tests (Unit + Integration), um Verhalten stabil zu halten, während Interna sich ändern
• Statische Analyse, um riskante Muster früh zu erkennen (Komplexität, unsichere Aufrufe, Abhängigkeitsprobleme)
• Sicherheitschecks (Dependency Scans, grundlegendes SAST), um Überraschungs‑Vulnerabilities zu verhindern

Ziel ist nicht Perfektion; Ziel ist, die Kosten für breaking changes zu erhöhen und die Kosten für sichere Verbesserungen zu senken.

Observability ist architektonisches Feedback

Gute Architektur heißt auch zu wissen, was in Produktion passiert. Ohne Feedback optimierst du nach Vermutungen.

• Logs zeigen, was während Incidents passierte (und warum).
• Metriken zeigen Trends: Fehlerraten, Latenz, Queue‑Tiefe, Saturation.
• Traces zeigen, wo Zeit über Servicegrenzen verloren geht.

Mit diesen Signalen kannst du Architekturentscheidungen mit Evidenz validieren, nicht mit Meinungen.

Release‑Sicherheit: ohne Angst ausliefern

Evolution erfordert häufige Releases; dafür brauchst du Fluchtmöglichkeiten. Feature‑Flags entkoppeln Deploy von Release. Canary‑Releases begrenzen die Blast‑Radius, indem sie nur einem kleinen Teil ausgerollt werden. Eine klare Rollback‑Strategie (inkl. DB‑Aspekte) macht Fehler wiederherstellbar.

Wenn du eine Plattform benutzt, die Snapshots und Rollbacks unterstützt (z. B. Koder.ai), kannst du dasselbe Prinzip auf Produktebene stärken: schnell handeln, aber Reversibilität und Betriebssicherheit als Defaults behalten.

CI/CD plus Feedback zusammen ergeben ein System, das kontinuierlich evolvieren kann — genau die Art von Architektur, die Trends überdauert.

Eine praktische Checkliste, um Fowlers Ideen dieses Quartal anzuwenden

Du brauchst keinen Rewrite, um bessere Architektur zu bekommen. Du brauchst einige wiederholbare Gewohnheiten, die Designprobleme sichtbar, reversibel und kontinuierlich verbesserbar machen.

Kurze Checkliste (für die Planung)

• Klarheit: Kann ein neuer Kollege die Hauptverantwortlichkeiten des Systems auf einer Seite erklären? Wenn nicht, füge pro Bereich ein kurzes README hinzu und beschreibe die "Form" des Systems.
• Grenzen: Haben Module/Services klare Ownership und Zweck, oder teilen sie Datenbanken, Utility‑Buckets und „God“‑Pakete? Wähle eine Grenze, die du stärkst.
• Tests als Sicherheit: Gibt es schnelle Tests, die Refactoring ohne Angst erlauben? Priorisiere dünne, wertvolle Coverage rund um den meiste Änderungsaufwand.
• Deployment: Kannst du kleine Änderungen häufig deployen? Wenn Releases schmerzhaft sind, mache Deployment zuerst langweilig, bevor du neue architektonische Komplexität hinzufügst.
• Ownership: Ist klar, wer was wartet? Richte Codegrenzen an Teamgrenzen aus, wo möglich, und mache diese Zuordnung explizit.

Ein 30/60/90‑Tage Verbesserungsplan

Nächste 30 Tage: Wähle einen Hotspot (hoher Churn, häufige Incidents). Füge eine Charakterisierungs‑Testsuite hinzu, vereinfache eine Abhängigkeitskette und beginne, leichte Entscheidungsnotizen für neue Änderungen zu schreiben.

Bis 60 Tage: Refaktoriere eine problematische Naht: Extrahiere ein Modul, definiere ein Interface oder isoliere Infrastruktur‑Belange (z. B. Persistence oder Messaging) hinter einer Grenze. Reduziere den "Blast Radius" von Änderungen.

Bis 90 Tage: Verbessere deine Lieferkette. Strebe kleinere PRs, schnellere Builds und eine vorhersehbare Release‑Kadenz an. Wenn du Microservices erwägst, belege den Bedarf: Zeige, dass eine Grenze innerhalb der bestehenden Codebasis nicht handhabbar ist.

(Wenn ein Teil deines Ziels ist, mehr Produkt mit weniger Handoffs zu liefern, überlege, wo Automatisierung helfen kann. Für einige Teams reduziert ein chat‑gesteuerter Build‑Workflow wie Koder.ai — mit Planungsmodus, Source‑Export, Deployment/Hosting, Custom Domains und abgestuften Preisen von kostenlos bis Enterprise — den mechanischen Overhead, sodass du architektonische Aufmerksamkeit auf Grenzen, Tests und operatives Feedback richten kannst.)

Messen von Ergebnissen, nicht Aufwand

Verfolge ein paar Signale monatlich:

• Lead Time vom Commit bis Produktion
• Change Failure Rate (Rollbacks, Hotfixes)
• Incident‑Volumen und wiederkehrende Ursachen

Wenn diese Werte sich nicht verbessern, passe den Plan an — Architektur ist nur „besser“, wenn sie Änderungen sicherer und günstiger macht.

Stacks werden sich weiter ändern. Die Grundlagen — klare Grenzen, Refactoring‑Disziplin und schnelles Feedback — bleiben bestehen.