Wie wir Systemarchitektur definieren, bevor wir Code schreiben

Viele Softwareprojekte scheitern nicht wegen schlechter Programmierung, sondern weil grundlegende Architekturentscheidungen erst getroffen werden, wenn das System bereits existiert. Wenn Architektur nur durch schrittweise Feature-Entwicklung entsteht, sammelt sich schnell technische Schuld an und Systeme werden unter Wachstum instabil.

Architektur vor der Implementierung zu planen bedeutet nicht, ein System zu überkomplizieren. Es bedeutet, die strukturelle Logik des Systems zu definieren, sodass Feature-Entwicklung innerhalb klarer Grenzen stattfindet.

Dieser Artikel beschreibt den Architektur-Vorbereitungsprozess, der in produktionsreifen Systemen vor Beginn der Entwicklung angewendet wird.

---

Warum Architektur vor Implementierung kommen muss

In frühen Produktphasen konzentrieren sich Teams häufig auf schnelle Feature-Entwicklung. Geschwindigkeit ist wichtig, doch unstrukturierte Entwicklung führt langfristig oft zu Problemen.

Typische Folgen sind:

• unklare Domänengrenzen im System
• starke Kopplung zwischen Frontend und Backend
• Datenbankschemata ohne langfristige Konsistenz
• instabile API-Schnittstellen
• Infrastrukturentscheidungen, die reaktiv statt geplant entstehen

Wenn sich diese Muster summieren, stehen Teams oft nach 12-18 Monaten vor einer vollständigen Systemneuentwicklung.

Architekturplanung reduziert dieses Risiko erheblich.

---

Schritt 1 - Systemdomänen definieren

Der erste Schritt besteht darin, die zentralen Domänen des Produkts zu identifizieren.

Eine Domäne ist ein logischer Verantwortungsbereich innerhalb des Systems. Beispiele sind:

• Benutzeridentität und Authentifizierung
• Abrechnung und Abonnements
• Produkt- oder Content-Management
• Analytics und Event-Tracking
• Kommunikationssysteme wie Benachrichtigungen oder Messaging

Jede Domäne sollte klar definierte Verantwortung für ihre Daten und Logik besitzen. Dadurch wird verhindert, dass Systemteile unkontrolliert voneinander abhängig werden.

In dieser Phase geht es noch nicht um Services oder Microservices, sondern um logische Trennung von Verantwortlichkeiten.

---

Schritt 2 - Datenverantwortung festlegen

Nachdem Domänen definiert sind, wird die Datenverantwortung festgelegt.

Jeder Datentyp im System sollte einen klaren Besitzer haben. Dadurch werden Konflikte zwischen Systemteilen reduziert und Inkonsistenzen vermieden.

Beispiel:

• User-Domäne: Accounts und Authentifizierungsdaten
• Billing-Domäne: Abonnements und Rechnungen
• Produkt-Domäne: Produkte, Katalog und Metadaten
• Analytics-Domäne: Events und Metriken

Ohne klare Verantwortlichkeiten entstehen häufig zirkuläre Abhängigkeiten, die später schwer zu lösen sind.

---

Schritt 3 - API-Vertraege definieren

Bevor Backendlogik implementiert wird, müssen API-Verträge zwischen Domänen definiert werden.

Ein API-Vertrag beschreibt:

• Request-Struktur
• Response-Struktur
• Validierungsregeln
• Fehlerbehandlung
• Versionierungsstrategie

Diese Verträge ermöglichen parallele Entwicklung von Frontend und Backend bei stabiler Integration.

Gut definierte Verträge reduzieren zudem das Risiko späterer Breaking Changes.

---

Schritt 4 - Systemgrenzen definieren

Nachdem Domänen und APIs definiert sind, werden Systemgrenzen festgelegt.

Diese bestimmen:

• welche Komponenten direkt kommunizieren dürfen
• welche Interaktionen über APIs laufen müssen
• welche Systeme Zugriff auf bestimmte Daten haben

Klare Grenzen verhindern, dass sich ein eng gekoppeltes System entwickelt, in dem jede Komponente von internen Details anderer Komponenten abhängt.

In frühen Produktphasen bleibt die Architektur häufig ein modularer Monolith, was oft die stabilste Struktur darstellt.

---

Schritt 5 - Infrastrukturannahmen definieren

Infrastruktur sollte die Architektur unterstützen und nicht bestimmen.

Typische Entscheidungen in dieser Phase betreffen:

• Deployment-Modell wie Container, Serverless oder Hybrid
• Datenbanksysteme
• Event-Verarbeitung
• Caching-Strategien
• Monitoring und Observability

Diese Entscheidungen stellen sicher, dass das System langfristig wachsen kann, ohne später strukturell umgebaut werden zu müssen.

---

Warum modulare Monolithen anfangs oft besser funktionieren

Viele frühe Teams setzen zu schnell auf Microservices.

Microservices bringen jedoch erhebliche operative Komplexität mit:

• Service-Orchestrierung
• verteiltes Debugging
• Kommunikation zwischen Services
• Herausforderungen bei Datenkonsistenz

Ein modularer Monolith schafft in frühen Produktphasen oft das beste Gleichgewicht. Deployment bleibt einfach, während die interne Architektur trotzdem sauber getrennt werden kann.

Wenn die Systemkomplexität später steigt, lassen sich klar definierte Domänen sicher in Services auslagern.

---

Architektur als Constraint System

Gute Architektur funktioniert eher als Constraint System als als starres Blueprint.

Anstatt jedes Implementierungsdetail vorzuschreiben, definiert Architektur:

• erlaubte Interaktionen zwischen Komponenten
• stabile Schnittstellen
• klare Verantwortungsgrenzen

Diese Struktur sorgt dafür, dass Teams sich schnell bewegen können, ohne die Integrität des Systems zu verlieren.

---

Fazit

Code zu schreiben, bevor Systemarchitektur definiert wurde, führt häufig zu fragilen Produkten, die später nur mit teuren Rewrites skalieren können.

Die Definition von Domänen, Datenverantwortung, API-Verträgen und Infrastrukturannahmen vor der Implementierung schafft eine stabile Grundlage für Wachstum.

Architektur bedeutet nicht, jede zukünftige Anforderung vorherzusehen. Sie schafft strukturelle Klarheit, damit Systeme wachsen können, ohne zu zerbrechen.