RelativesService
Component Detail
Service Layer
medium complexity
backend
0
Dependencies
0
Dependents
1
Entities
0
Integrations
Description
Business logic layer responsible for creating and managing relative contact records linked to a primary contact. Enforces domain rules around relationship types and communication preferences before delegating persistence to the repository. Acts as the bridge between the UI layer and the data layer.
relatives-service
Sources & reasoning
Barnekreftforeningen explicitly requires registering relatives as independent contact subjects (line 121). Priority matrix confirms MUST with Phase 1 placement (line 161) and the note at line 438 reinforces the Fase 1 mandate. Blueprint marks this feature [MVP]. All downstream relatives-database features depend on this registration capability existing first.
-
docs/source/likeperson.md · line 121Barnekreftforeningen jobber primært med familier rundt barn med kreft, ikke kun med de berørte selv. Appen må støtte registrering av pårørende (foreldre, søsken, nærmeste omsorgsperson) som egne kontaktsubjekter
-
docs/source/likeperson.md · line 161Pårørende database | ✓ | - | - | - | ✓ | MUST (Barnekreft) | 1
-
docs/source/likeperson.md · line 438Pårørende-database er Fase 1 MUST for Barnekreftforeningen (se §4 matrisen).
Responsibilities
- Validate relative registration data against domain rules before persisting
- Coordinate creation of relative records linked to a given primary contact ID
- Expose retrieval methods for fetching all relatives associated with a contact
- Handle errors from the repository and translate them into domain-level exceptions
- Enforce constraints such as preventing duplicate relative entries for the same contact
Interfaces
registerRelative(contactId: string, data: RelativeRegistrationData): Promise<Relative>
getRelativesByContact(contactId: string): Promise<Relative[]>
updateRelative(relativeId: string, data: Partial<RelativeRegistrationData>): Promise<Relative>
deleteRelative(relativeId: string): Promise<void>