Architektur
Modulgrenzen
Bounded Contexts Check / PBZ / Lead
Check — Modulgrenzen & Bounded Contexts
Abgrenzung für HonestCom Check, Vorbereitung und geplantes PBZ (Persönlicher Bestzinsbogen). Ziel: keine Monolithen in API, Domain oder UI.
Kontexte
| Context | Verantwortung | Darf importieren |
|---|---|---|
| check-domain | Rechenlogik, Texte, Typen, PBZ-Regeln (pure) | nur stdlib / Zod |
| check-api | app/api/check/*, Auth, Rate-Limits | check-domain, db, encryption |
| check-web | components/check/*, /check Routes | check-domain (lesen), API |
| lead-dossier | dossier.ts, Lead-Detail, Mails | check-domain, db |
| pbz (geplant) | Fortschritt, PATCH-Sektionen, Validierung | check-domain, db (Lead.answers) |
Regeln
- Domain vor UI —
lib/check/*ohnenext/*, ohne React. - Ein Zod-Schema pro mutierender Route —
lib/validation/check.ts, künftigpbz.ts. - Token-Gates — öffentlicher Check vs.
publicTokenfür Vorbereitung/PBZ; Berater nur per Session. - Keine Quer-Imports — PBZ-UI nicht in Lead-Tabellen; Dossier baut auf Domain-Funktionen, nicht auf React-State.
API-Oberfläche (Ist / Soll)
| Route | Context | Status |
|---|---|---|
POST /api/check/leads | check-api | live |
GET/PATCH /api/check/leads/[token] | check-api | live |
PATCH …/pbz (Sektionen) | pbz | geplant (PBZ-PR) |
OpenAPI: modular unter openapi/ (Cross-Platform-PR), getrennt check vs. pbz.
PBZ & Internal-Doku
Der ausführliche PBZ-Integrationsplan liegt aktuell im HonestCom Project Store (pbz-app-integration-plan.md), nicht im öffentlichen Repo — bis Freigabe nur intern verlinken.