Softwarearchitektur in der Praxis: 7 Entscheidungen, die Systeme langfristig tragfähig machen

Gute Softwarearchitektur erkennst du nicht an der Zahl ihrer Services, Diagramme oder Frameworks. Du erkennst sie daran, dass ein Team das System auch nach Jahren noch sicher verändern, betreiben und bei Bedarf zurückbauen kann.

Ich arbeite seit mehr als 14 Jahren an Webplattformen. Die langlebigsten Systeme waren selten die technisch spektakulärsten. Sie hatten klare Grenzen, wenige notwendige Abhängigkeiten und Entscheidungen, deren Konsequenzen das Team verstanden hat.

Dieser Artikel ist deshalb kein Katalog von Architekturmustern. Er ist ein praktischer Rahmen für sieben Entscheidungen, die vor einem neuen Service, einer Datenbank oder einem großen Umbau beantwortet werden sollten.

1. Welches Problem soll die Architektur lösen?

„Wir brauchen Microservices“ ist keine Anforderung. Eine belastbare Anforderung klingt eher so:

• zwei Teams blockieren sich regelmäßig bei Releases,
• ein Teil des Systems hat deutlich andere Last- oder Verfügbarkeitsanforderungen,
• sensible Daten brauchen eine eigene Zugriffsgrenze,
• eine Komponente muss unabhängig ersetzt werden können,
• oder ein monolithischer Deploy dauert so lange, dass Fehlerkorrekturen riskant werden.

Erst wenn das konkrete Problem sichtbar ist, lässt sich beurteilen, ob eine neue Grenze wirklich hilft. Ohne diesen Bezug verschiebt Architektur oft nur Komplexität: aus einem Prozess werden mehrere Deployments, Netzwerkanfragen, Berechtigungen und Fehlerfälle.

Meine Standardfrage lautet: Welche messbare oder beobachtbare Einschränkung verschwindet durch diese Entscheidung? Wenn darauf keine klare Antwort folgt, bleibt die einfachere Struktur zunächst bestehen.

2. Wo liegt die fachliche Verantwortung?

Dateien und Ordner sind noch keine Architektur. Entscheidend ist, wer eine fachliche Regel besitzt.

Eine gute Grenze fasst Daten, Regeln und Änderungen zusammen, die denselben Zweck haben. Eine schlechte Grenze verteilt eine Entscheidung über Controller, Jobs, Datenbankskripte und drei Services. Dann muss jede kleine Änderung an mehreren Stellen synchron erfolgen.

Praktisch hilft eine kurze Zuordnung:

Das reduziert nicht nur Kopplung. Es verhindert auch, dass Sicherheits-, Abrechnungs- oder Löschregeln in unterschiedlichen Pfaden auseinanderlaufen.

3. Welche Daten gehören zusammen?

Die Wahl der Datenbank ist meist weniger wichtig als die Eigentumsfrage: Welche Komponente darf welche Daten schreiben, und welche Konsistenz muss erhalten bleiben?

Bei einer klassischen Webanwendung ist eine gemeinsame relationale Datenbank oft die einfachste und sicherste Lösung. Getrennte Datenbanken werden sinnvoll, wenn eine echte Isolations-, Lebenszyklus- oder Skalierungsgrenze existiert. Sie erzeugen aber neue Aufgaben:

• verteilte Änderungen brauchen Ausgleichs- oder Wiederholungslogik,
• Exporte und Löschvorgänge müssen mehrere Speicherorte erfassen,
• Backups müssen zueinander passen,
• und Berichte brauchen eine definierte Sicht auf mehrere Datenquellen.

Bei HitKeep habe ich bewusst eine andere Richtung gewählt: Die selbst gehostete Anwendung bleibt ein einzelnes Go-Binary mit eingebetteter Speicherung und Queue. Das ist keine allgemeine Empfehlung gegen externe Datenbanken. Es ist eine Entscheidung für einen kleinen Betriebsumfang, weil das Produkt als eigenständige Analytics-Anwendung ausgeliefert wird.

Die Architektur passt, solange ihre Grenzen zu Last, Datenmenge und Betriebsmodell passen. Die aktuellen Grenzen gehören deshalb genauso zur Dokumentation wie die Vorteile: HitKeep Fakten und Grenzen.

4. Wer betreibt die zusätzliche Komplexität?

Jede technische Komponente hat einen Preis, auch wenn ihre Lizenz kostenlos ist. Ein neuer Service braucht mindestens:

• Deployment und Konfiguration,
• Updates und Sicherheitsbeobachtung,
• Backups oder Wiederaufbau,
• Monitoring und Alarmierung,
• Zugriffsregeln und Geheimnisse,
• sowie jemanden, der Fehler außerhalb der Arbeitszeit versteht.

Deshalb bewerte ich Architektur nicht nur nach Entwicklungszeit. Ich frage, ob das Team die neue Komponente drei Jahre lang zuverlässig betreiben kann. Genau diese Trennung zwischen einem nachbaubaren Funktionskern und dauerhaftem Betriebsrisiko steckt auch hinter meinen Bewertungen auf Kann KI das?.

Ein kleineres System ist nicht automatisch besser. Aber Komplexität sollte eine konkrete Anforderung bezahlen, nicht nur eine technische Vorliebe.

5. Wie wird die Entscheidung migriert und zurückgenommen?

Architekturänderungen scheitern selten an der neuen Zielstruktur. Sie scheitern am Weg dorthin.

Vor dem Umbau sollten vier Schritte klar sein:

1. Kompatibilität: Kann alter und neuer Code zeitweise mit demselben Zustand arbeiten?
2. Datenbewegung: Wie werden bestehende Daten kopiert, geprüft und nachgezogen?
3. Umschaltung: Welcher kleine, beobachtbare Schritt wechselt den aktiven Pfad?
4. Rückbau: Was kann bei fehlerhaften Ergebnissen ohne Datenverlust zurückgedreht werden?

Eine Migration ist sicherer, wenn sie in kleinen kompatiblen Schritten erfolgt. Erst die neue Struktur hinzufügen, dann Daten und Leser umstellen, danach Schreiber wechseln und am Ende die alte Struktur entfernen. Große „Big Bang“-Umbauten sparen scheinbar Zwischenarbeit, machen aber Fehler schwerer einzugrenzen.

6. Wie wird das Verhalten bewiesen?

Ein Diagramm zeigt Absichten. Tests, Metriken und Betriebsabläufe zeigen, ob die Architektur wirklich trägt.

Für eine wichtige Grenze brauche ich mindestens:

• einen automatisierten Test der zentralen Regel,
• einen Test des Fehlers oder Ausfalls,
• sichtbare Metriken für Durchsatz, Fehler und Dauer,
• einen dokumentierten Wiederherstellungsweg,
• und einen Export- oder Takeout-Pfad für wichtige Daten.

Dabei sollte die Beobachtung zur Entscheidung passen. Eine Queue braucht zum Beispiel nicht nur CPU-Metriken, sondern auch Rückstau, Alter der ältesten Nachricht und Fehlversuche. Eine Mandantengrenze braucht nicht nur funktionale Tests, sondern Belege dafür, dass Daten nicht zwischen Mandanten gelesen oder gelöscht werden.

7. Wann wird neu bewertet?

Eine Architekturentscheidung ist keine ewige Wahrheit. Notiere bei größeren Entscheidungen deshalb nicht nur das Ergebnis, sondern auch die Annahmen und den Auslöser für eine Neubewertung.

Ein kurzer Entscheidungsnachweis reicht:

Entscheidung: Ein gemeinsamer Dienst bleibt bestehen.
Grund: Ein Team, gemeinsamer Datenlebenszyklus, gleiche Skalierungsanforderungen.
Akzeptierter Nachteil: Releases bleiben gekoppelt.
Neu bewerten, wenn: Zwei Teams unabhängig releasen müssen oder der Dienst ein eigenes Lastprofil entwickelt.
Rückbau/Migration: Schnittstelle und Datenbesitz sind bereits klar getrennt.

So verhindert das Team zwei typische Fehler: eine alte Entscheidung aus Gewohnheit zu verteidigen oder sie ohne Kenntnis ihrer damaligen Gründe zu ersetzen.

Mein Entscheidungsrahmen in Kurzform

Bevor ich eine neue Architekturkomponente einführe, müssen diese Fragen beantwortet sein:

1. Welches konkrete Problem löst sie?
2. Welche fachliche Verantwortung besitzt sie?
3. Welche Daten und Regeln gehören zu dieser Grenze?
4. Wer betreibt sie dauerhaft?
5. Wie erfolgt die Migration ohne Datenverlust?
6. Welche Tests und Metriken beweisen das Verhalten?
7. Welcher Auslöser führt zu einer Neubewertung?

Wenn eine kleinere Lösung dieselben Antworten liefert, ist sie meist die bessere Ausgangslage. Wenn eine neue Grenze echte Team-, Sicherheits-, Daten- oder Skalierungsprobleme löst, sollte sie genau dort eingeführt werden – mit einem klaren Betriebs- und Rückbauweg.

Weitere konkrete Projekte und technische Entscheidungen findest du unter Projekte und Kompetenzen. Meine Regeln für Quellen, Korrekturen und KI-unterstützte Inhalte stehen in den redaktionellen Richtlinien.