## Kritische Architekturprobleme

### 1. Fataler Tenant-Isolation-Fehler

Das Datenmodell nennt sowohl `organisation_id` als auch `tenant_id`, aber ohne klare Abgrenzung. Dies ist ein **kritischer Designfehler**:

```
# Problem in data-model-v0.1.md:
"Von Anfang an vorbereiten:
- organisation_id
- tenant_id"
```

**Warum kritisch:** 
- Unklare Hierarchie zwischen Organisation und Tenant
- Potenzielle Tenant-Leaks durch falsche Filterung
- Kein explizites Constraint-Modell definiert

**Lösung erforderlich:** Eine klare Entscheidung - entweder Organisation ODER Tenant, nicht beides halbherzig.

### 2. Secrets-Management ohne Implementierung

Das Security-Dokument behauptet:
```
"Secrets werden nur über einen Secret-Service gelesen/geschrieben"
```

Aber:
- Kein Secret-Service definiert
- Registrar-Account hat "Zugangsdaten/API-Referenzen" direkt im Modell
- Keine Encryption-at-Rest-Strategie

**Risiko:** Passwörter landen im Klartext in der Datenbank.

### 3. Audit-Log Hash-Chain ist Pseudo-Security

ADR 0014 schlägt eine Hash-Chain vor, aber:
- Kein Schutz gegen DB-Admin-Manipulation
- Hash-Algorithm nicht spezifiziert
- "V1 bereitet vor" = wird nicht implementiert

**Problem:** Security-Theater ohne echten Schutz. Ein DB-Admin kann die gesamte Chain neu berechnen.

### 4. Dead Letter Queue ohne Retention-Strategie

ADR 0017 fordert Dead Letter Queues, aber:
- Keine maximale Retention definiert
- Potenzielle Speicher-Explosion
- DSGVO-Konflikt bei personenbezogenen Daten in fehlgeschlagenen Jobs

### 5. Fehlende Core-Domain-Boundaries

Das Datenmodell mischt alles:
- Billing (Rechnung, Zahlung)
- Provisioning (Server, Hostingpaket)
- CRM (Kunde, Ticket)
- Registry (Domain, Registrar)

**Problem:** Keine Bounded Contexts = massive Kopplung, unmöglich zu skalieren.

### 6. Reconciliation ohne Event-Sourcing

ADR 0017 fordert Reconciliation, aber das Datenmodell hat keine Event-Historie. Wie soll man reconcilen ohne zu wissen, was passiert ist?

### 7. Security-Rollen ohne Scope-Definition

"Staff/Support" hat Zugriff auf "operative Daten" - was heißt das konkret?
- Kann Support Passwörter sehen?
- Kann Support Rechnungen ändern?
- Kann Support Server-Zugänge einsehen?

### 8. Single Point of Failure: tenant_id

Alles hängt an einem einzigen Feld. Ein fehlerhafter Query-Scope = Datenleck über alle Mandanten.

**Fehlende Sicherheitsschicht:**
- Kein Row-Level-Security auf DB-Ebene
- Keine Tenant-Context-Validierung
- Kein Fail-Safe-Mechanismus

### 9. Dokument-Objekt ohne Storage-Strategy

"Dokument" hat "Hashes" und "Archivinformationen", aber:
- Wo werden Dateien gespeichert?
- Wie wird Tenant-Isolation im Filesystem sichergestellt?
- Was passiert bei Löschanfragen?

### 10. Keine Migrationsstrategie für Multi-Tenancy

"V1 arbeitet als Single-Tenant" aber "Struktur vorbereitet" - das ist ein Widerspruch. Entweder man designed multi-tenant von Anfang an oder man plant eine Migration. Beides fehlt.

## Fazit

Die Architektur versucht, zu viele Probleme gleichzeitig zu lösen, ohne eines davon richtig zu durchdenken. Kritischster Punkt: Die Tenant-Isolation ist nur oberflächlich geplant und wird mit hoher Wahrscheinlichkeit zu Datenleaks führen.