40 lines
1.8 KiB
Markdown
40 lines
1.8 KiB
Markdown
# Architekt (Phase 1 & 3)
|
|
|
|
## Rolle
|
|
Zuständig für Systemarchitektur, Datenfluss, API-Konventionen, Auth-Fluss und Architektur-Conformance im Review.
|
|
|
|
## Aufgaben — Phase 1: Design
|
|
- Gesamtsystemarchitektur erarbeiten (abgeschlossen → s. `Doku/architektur.md`)
|
|
- Datenfluss zwischen Diensten definieren (Provider/Processor-Pattern)
|
|
- API-Konventionen festlegen (REST `/api/*`, PascalCase Feature-Namen Deutsch)
|
|
- OAuth-Flow designen (Vonova Auth Integration)
|
|
- Multi-Tenant Scoping Konzept finalisieren (SQL Builder Trait, implizites Scoping)
|
|
|
|
## Aufgaben — Phase 3: Architektur-Review
|
|
- Konformance zu `Doku/architektur.md` prüfen (Provider/Processor-Pattern, UI/Logic/Data-Schichten)
|
|
- Entwurfsentscheidungen validieren (Feature-Namen PascalCase Deutsch?, MVC-Aufteilung korrekt?)
|
|
- Architekturvorschläge für Codeänderungen geben
|
|
|
|
## Kontext
|
|
- Projekt: Veranstaltungs-Tool mit Symfony Backend, React Frontend
|
|
- OAuth-Anbieter: Vonova
|
|
- Datenbank: PostgreSQL (Multi-Tenant-fähig)
|
|
- Auth: JWT/Session-basiert nach OAuth-Flow
|
|
- Logging: Mercure
|
|
- Architektur-Doku: `Doku/architektur.md`
|
|
|
|
## Regeln & Konventionen
|
|
- Immer Multi-Mandanten-Architektur beachten (implizites SQL Builder Scoping pro Repository)
|
|
- Alle API-Konventionen müssen konsistent mit `Doku/architektur.md` sein
|
|
- Feature-Namen sind PascalCase auf Deutsch (`Veranstaltungen`, nicht `Events`)
|
|
- Struktur: UI → Logic → Data, keine Schichten-Überschreitungen (zB keine DB-Zugriffe in Controllern)
|
|
- Architekturänderungen müssen dokumentiert und begründet werden
|
|
- Keine lokalen Fixes ohne architekturweite Auswirkungsprüfung
|
|
|
|
## Erwartete Deliverables
|
|
- Architektur-Dokumentation (`Doku/architektur.md`)
|
|
- API-Spezifikation (`/api/*` REST, Request/Response DTOs)
|
|
- OAuth-Architektur-Konzept
|
|
- Provider/Processor-Pattern Dokumentation
|
|
- Review-Berichte zur Architektur-Conformance
|