review-software-architectureBewertet Softwarearchitektur auf Kopplung, Kohaesion, SOLID-Prinzipien, API-Design, Skalierbarkeit und technische Schulden. Umfasst systemweite Bewertung, Review von Architecture Decision Records und Verbesserungsempfehlungen. Verwenden bei der Bewertung einer vorgeschlagenen Architektur vor der Implementierung, beim Assessment eines bestehenden Systems auf…
Independent GitHub snapshot · Automated classification · Original documentation governs
Softwarearchitektur auf Systemebene hinsichtlich Qualitaetsattribute, Einhaltung von Designprinzipien und langfristiger Wartbarkeit bewerten.
Systemgrenzen und Schnittstellen erfassen:
## Systemkontext
- **Name**: [Systemname]
- **Zweck**: [Einzeilige Beschreibung]
- **Nutzer**: [Wer es nutzt und wie]
- **Groessenordnung**: [Anfragen/Sek., Datenvolumen, Nutzerzahl]
- **Alter**: [Jahre im Produktionsbetrieb, Hauptversionen]
- **Team**: [Groesse, Zusammensetzung]
## Externe Abhaengigkeiten
| Abhaengigkeit | Typ | Kritikalitaet | Anmerkungen |
|-----------|------|-------------|-------|
| PostgreSQL | Datenbank | Kritisch | Primaerer Datenspeicher |
| Redis | Cache | Hoch | Session-Speicher + Caching |
| Stripe | Externe API | Kritisch | Zahlungsabwicklung |
| S3 | Objektspeicher | Hoch | Datei-Uploads |
Erwartet: Klares Bild davon, was das System tut und wovon es abhaengt. Bei Fehler: Wenn die Architekturdokumentation fehlt, den Kontext aus Codestruktur, Konfigurationen und Deployment-Dateien ableiten.
Untersuchen, wie stark Module voneinander abhaengen:
# Detect circular dependencies (JavaScript/TypeScript)
npx madge --circular src/
# Detect import patterns (Python)
# Look for deep cross-package imports
grep -r "from app\." --include="*.py" | sort | uniq -c | sort -rn | head -20
Bewerten, ob jedes Modul eine einzige, klare Verantwortung hat:
| Kopplungsniveau | Beschreibung | Beispiel |
|---|---|---|
| Niedrig (gut) | Module kommunizieren ueber Schnittstellen | Service A ruft die API von Service B auf |
| Mittel | Module teilen Datenstrukturen | Gemeinsame DTO/Modell-Bibliothek |
| Hoch (Bedenken) | Module referenzieren Interna des anderen | Direkter Datenbankzugriff ueber Module |
| Pathologisch | Module veraendern den internen Zustand des anderen | Globaler veraenderlicher Zustand |
Erwartet: Kopplung und Kohaesion mit spezifischen Beispielen aus der Codebasis bewertet. Bei Fehler: Wenn die Codebasis fuer ein manuelles Review zu gross ist, 3-5 Schluesselmodule und die am haeufigsten geaenderten Dateien stichprobenartig pruefen.
| Prinzip | Frage | Warnzeichen |
|---|---|---|
| Single Responsibility | Hat jede Klasse/jedes Modul einen einzigen Aenderungsgrund? | Klassen mit >5 oeffentlichen Methoden zu unzusammenhaengenden Belangen |
| Open/Closed | Kann Verhalten erweitert werden, ohne bestehenden Code zu aendern? | Haeufige Aenderungen an Kernklassen fuer jedes neue Feature |
| Liskov-Substitution | Koennen Untertypen ihre Basistypen ersetzen, ohne das Verhalten zu brechen? | Typprüfungen (instanceof) ueber Consumer-Code verstreut |
| Interface Segregation | Sind Schnittstellen fokussiert und minimal? | "Fette" Schnittstellen, bei denen Konsumenten ungenutzte Methoden implementieren |
| Dependency Inversion | Haengen hochwertige Module von Abstraktionen ab, nicht von Details? | Direkte Instanziierung von Infrastrukturklassen in der Geschaeftslogik |
## SOLID-Bewertung
| Prinzip | Status | Nachweis | Auswirkung |
|-----------|--------|----------|--------|
| SRP | Bedenken | UserService behandelt Auth, Profil, Benachrichtigungen und Abrechnung | Hoch — Aenderungen an der Abrechnung riskieren, Auth zu brechen |
| OCP | Gut | Plugin-System fuer Zahlungsanbieter | Niedrig |
| LSP | Gut | Keine Typ-Check-Anti-Patterns gefunden | Niedrig |
| ISP | Bedenken | IRepository hat 15 Methoden, die meisten Implementierungen nutzen 3-4 | Mittel |
| DIP | Bedenken | Controller instanziieren Datenbankrepositories direkt | Mittel |
Erwartet: Jedes Prinzip mit mindestens einem spezifischen Beispiel bewertet. Bei Fehler: Nicht alle Prinzipien gelten gleich fuer jeden Architekturstil. Vermerken, wenn ein Prinzip weniger relevant ist (z. B. ISP weniger wichtig in funktionalen Codebases).
Fuer Systeme, die APIs exponieren (REST, GraphQL, gRPC):
## API-Design-Review
| Aspekt | Status | Anmerkungen |
|--------|--------|-------|
| Namenskonsistenz | Gut | Durchgaengige RESTful-Ressourcenbenennung |
| Versionierung | Bedenken | Keine Versionierungsstrategie — Breaking Changes betreffen alle Clients |
| Fehlerformat | Gut | RFC 7807 Problem Details konsistent verwendet |
| Auth | Gut | JWT mit rollenbasierten Scopes |
| Rate Limiting | Fehlend | Kein Rate Limiting an irgendeinem Endpunkt |
| Dokumentation | Bedenken | OpenAPI-Spec vorhanden, aber 6 Monate veraltet |
Erwartet: API-Design gegen gaengige Standards reviewed mit spezifischen Befunden. Bei Fehler: Wenn keine API exponiert wird, diesen Schritt ueberspringen und sich auf interne Modulschnittstellen konzentrieren.
Erwartet: Skalierbarkeit und Zuverlaessigkeit relativ zu formulierten nichtfunktionalen Anforderungen bewertet. Bei Fehler: Wenn nichtfunktionale Anforderungen undokumentiert sind, deren Definition als ersten Schritt empfehlen.
## Technische-Schulden-Inventar
| Punkt | Schweregrad | Auswirkung | Geschaetzter Aufwand | Empfehlung |
|------|----------|--------|-----------------|----------------|
| Keine Datenbankmigrationen | Hoch | Schaemaenderungen sind manuell und fehleranfaellig | 1 Sprint | Alembic/Flyway einfuehren |
| Monolithische Test-Suite | Mittel | Tests dauern 45 min, Entwickler ueberspringen sie | 2 Sprints | In Unit/Integration/E2E aufteilen |
| Hartcodierte Konfigurationswerte | Mittel | Umgebungsspezifische Werte im Quellcode | 1 Sprint | In Env-Variablen/Konfigurationsdienst auslagern |
| Keine CI/CD-Pipeline | Hoch | Manuelle Deployments fehleranfaellig | 1 Sprint | GitHub Actions einrichten |
Erwartet: Technische Schulden mit Schweregrad, Auswirkung und Aufwandsschaetzungen katalogisiert. Bei Fehler: Wenn das Schuldeninventar ueberwaetigend ist, die 5 wichtigsten Punkte nach Auswirkungs-/Aufwandsverhaeltnis priorisieren.
Wenn ADRs vorhanden sind, beurteilen:
Wenn ADRs nicht vorhanden sind, deren Einfuehrung fuer Schluesselelentscheidungen empfehlen.
## Architektur-Review-Bericht
### Zusammenfassung
[2-3 Saetze: Gesamtzustand, wesentliche Bedenken, empfohlene Massnahmen]
### Staerken
1. [Spezifische architektonische Staerke mit Nachweis]
2. ...
### Bedenken (nach Schweregrad)
#### Kritisch
1. **[Titel]**: [Beschreibung, Auswirkung, Empfehlung]
#### Wesentlich
1. **[Titel]**: [Beschreibung, Auswirkung, Empfehlung]
#### Geringfuegig
1. **[Titel]**: [Beschreibung, Empfehlung]
### Zusammenfassung technischer Schulden
[Top-5-Schulden mit priorisierten Empfehlungen]
### Empfohlene naechste Schritte
1. [Umsetzbare Empfehlung mit klarem Umfang]
2. ...
Erwartet: Review-Bericht ist umsetzbar mit priorisierten Empfehlungen. Bei Fehler: Wenn der Review zeitlich begrenzt ist, klar angeben, was abgedeckt wurde und was unbewertet bleibt.
code-reviewer fuer PR-Feedback verwenden.security-audit-codebase — sicherheitsfokussiertes Code- und Konfigurationsreviewconfigure-git-repository — Repository-Struktur und Konventionendesign-serialization-schema — Datenschema-Design und -Entwicklungreview-data-analysis — Review auf analytische Korrektheit (ergaenzende Perspektive)