ReferralRepository
Component Detail
Data Layer
medium complexity
backend
0
Dependencies
0
Dependents
0
Entities
0
Integrations
Description
Data access layer for all referral token and attribution records. It handles persistence of tokens, attribution events, and click counts, providing typed query methods used exclusively by ReferralService.
referral-repository
Sources & reasoning
HLF named referral / member recruitment as a SHOULD HAVE requirement and the priority matrix assigns it Phase 3 (Fase 3), which maps to v1.1. The invite-link and QR sharing mechanism is the entry point of the referral flow - without it, recruitment tracking has nothing to count. Blueprint ID invite-link-qr-sharing is preserved exactly as specified.
-
docs/source/likeperson.md · line 117**Vervefunksjonalitet** for medlemsverving (appen som markedsført medlemsfordel).
-
docs/source/likeperson.md · line 162| Verving / Referral (invite-link, rekruttering) | - | - | - | ✓ | ✓ | SHOULD (HLF) | 3 |
-
docs/source/likeperson.md · line 360- Verving / Referral (HLF)
Responsibilities
- Persist newly generated referral tokens with owner user ID and creation timestamp
- Query a token record by its token string for resolution and validation
- Insert attribution records when a referred user completes sign-up
- Aggregate click and conversion counts per mentor for statistics queries
- Soft-delete or mark tokens inactive without removing attribution history
Interfaces
createToken(record: ReferralTokenRecord): ReferralTokenRecord
findByToken(token: string): ReferralTokenRecord | null
saveAttribution(event: ReferralAttributionEvent): void
getStatsByOwner(userId: string): ReferralStats
deactivateToken(token: string): void