Architektur-Review

Das Problem

Architekturentscheidungen summieren sich ueber die Zeit. Ein eng gekoppeltes Modul, das bei 500 Zeilen harmlos wirkt, wird bei 5.000 Zeilen zum unwartbaren Monolithen. Teams liefern Features aus, ohne die Abhaengigkeitsrichtung, Abstraktionsgrenzen oder tatsaechliche Einhaltung des Single-Responsibility-Prinzips zu hinterfragen. Wenn die Architekturschmerzen sichtbar werden, haben sich die Refactoring-Kosten verzehnfacht.

Der Prompt

Pruefe die Architektur der folgenden Codebasis. Handle als Principal Engineer, der das System auf langfristige Skalierbarkeit und Wartbarkeit bewertet.

KONTEXT: [z.B. "E-Commerce Checkout-Service, 3 Entwickler, Node.js/Express"]
DATEISTRUKTUR:
[Verzeichnisbaum oder wichtige Dateipfade einfuegen]

CODE:
[Wichtige Module/Dateien einfuegen]

Bewerte in diesen Architektur-Dimensionen:

1. **SOLID-Konformitaet**
   - Single Responsibility: Hat jedes Modul/jede Klasse nur einen Aenderungsgrund?
   - Open/Closed: Kann Verhalten erweitert werden, ohne bestehenden Code zu aendern?
   - Liskov Substitution: Sind Subtypen wirklich austauschbar?
   - Interface Segregation: Sind Interfaces schlank oder aufgeblaeht?
   - Dependency Inversion: Abhaengen High-Level-Module von Abstraktionen?

2. **Kopplungsanalyse**
   - Abhaengigkeiten zwischen Modulen kartieren. Zirkulaere Abhaengigkeiten identifizieren.
   - Kopplung bewerten: eng (direkte Objektreferenzen) / lose (Interfaces/Events) / keine.
   - God Objects markieren, die zu viel ueber andere Module wissen.

3. **Kohaesionsbewertung**
   - Gruppiert jedes Modul zusammengehoerige Funktionalitaet?
   - Shotgun-Surgery-Risiken identifizieren (eine Aenderung betrifft 5+ Dateien).
   - Utility-Sammelstellen mit unrelatierter Funktionalitaet markieren.

4. **Abstraktionsgrenzen**
   - Sind Schichtgrenzen klar (Controller → Service → Repository)?
   - Leckt Geschaeftslogik in Transport- oder Persistenzschichten?
   - Sind Querschnittsbelange (Auth, Logging, Validierung) zentralisiert?

5. **Evolutionsbereitschaft**
   - Wie aufwaendig waere ein Datenbankwechsel? Ein Frameworkwechsel? Ein neuer API-Konsument?
   - Vendor Lock-in oder Framework-Kopplung identifizieren.

Fuer jedes Finding liefere:
- **Ort**: Betroffenes Modul/Datei
- **Schweregrad**: Strukturelle-Schulden / Design-Smell / Verbesserung
- **Auswirkung**: Was bei wachsender Codebasis bricht oder degradiert
- **Empfehlung**: Konkretes Refactoring mit Vorher/Nachher-Skizze

Beispielausgabe

## Architektur-Review: Checkout-Service

### Strukturelle Schulden: God-Service-Pattern
Ort: `src/services/OrderService.ts` (847 Zeilen)
Auswirkung: Verarbeitet Payment, Inventar, E-Mail und Analytics — jede Aenderung riskiert Seiteneffekte.
Empfehlung: In PaymentService, InventoryService, NotificationService aufteilen.
OrderService wird zum Orchestrator:

  async createOrder(dto: CreateOrderDTO) {
    const payment = await this.paymentService.charge(dto);
    await this.inventoryService.reserve(dto.items);
    await this.notificationService.sendConfirmation(payment);
  }

### Design Smell: Zirkulaere Abhaengigkeit
Ort: UserModule ↔ OrderModule (importieren sich gegenseitig)
Auswirkung: Nicht unabhaengig testbar oder deploybar. Bundle-Splitting unmoeglich.
Empfehlung: Geteilte Typen in ein `@shared/types`-Paket extrahieren. Event Bus fuer moduluebergreifende Kommunikation verwenden.

Wann verwenden

Ausfuehren beim Start einer neuen Projektphase, beim Onboarding in eine bestehende Codebasis oder vor einem grossen Feature, das bestehende Grenzen belasten wird. Architektur-Reviews sind am wertvollsten, bevor sich die Codebasis verdoppelt — sie decken Risse auf, die zu Abgruenden werden.

Profi-Tipps

• Dateibaum einbeziehen — Architekturprobleme leben in den Beziehungen zwischen Dateien, nicht innerhalb einzelner. Immer die Verzeichnisstruktur mitliefern.
• An der Grenze reviewen — auf die Kommunikation zwischen Modulen fokussieren, nicht auf die interne Implementierung. Die Schnittstelle verraet mehr als der Code dahinter.
• Abhaengigkeitsgraph anfordern — “Zeichne einen ASCII-Abhaengigkeitsgraphen der Modulbeziehungen” fuer eine visuelle Kopplungsuebersicht.
• Evolutionsszenarien testen — “Wie wuerde diese Architektur GraphQL neben REST handhaben?” anfuegen, um Flexibilitaet zu pruefen.