Service Layer medium complexity backend
0
Dependencies
0
Dependents
2
Entities
0
Integrations

Description

Business logic layer that handles creation and management of relative contact records. It enforces domain rules such as valid relationship roles and case linkage, and coordinates between the UI layer and RelativeRepository. It also handles deduplication checks before persisting new records.

Feature: Relative Contact Registration

relative-service

Sources & reasoning

Source lines 121-122 explicitly define the relative registration requirement as unique to Barnekreftforeningen. Line 161 (priority matrix) marks it MUST with Phase 1. Line 438 reconfirms Fase 1 MUST status. Phase 1 maps to MVP by ordinal. This is the foundational record-creation step the other two relatives features depend on.

  • docs/source/likeperson.md · line 121-122
    Pårørende-database: Barnekreftforeningen 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 knyttet til samme
  • docs/source/likeperson.md · line 161
    Pårørende database | ✓ | - | - | - | ✓ | MUST (Barnekreft) | 1
  • docs/source/likeperson.md · line 438
    Pårørende-database er Fase 1 MUST for Barnekreftforeningen

Responsibilities

  • Validate relative contact data against domain rules before persistence
  • Check for duplicate relative records within the same case
  • Delegate storage and retrieval operations to RelativeRepository
  • Emit events or notifications when a new relative is registered
  • Support updating and soft-deleting existing relative records

Interfaces

registerRelative(data: RelativeInput): Promise<Relative>
updateRelative(relativeId: string, data: Partial<RelativeInput>): Promise<Relative>
getRelativesByCase(caseId: string): Promise<Relative[]>
deleteRelative(relativeId: string): Promise<void>

Related Data Entities (2)

Data entities managed by this component