Event Sourcing & Datamodell

Oversikt

Systemet bruker Event Sourcing Light - alle endringer lagres som immutable events som kan prosesseres uavhengig på tre parallelle spor.

Kjerneprinsipp

Events (immutable) → Projeksjon → SakState (computed view)

• Events lagres i Supabase event store
• SakState beregnes fra event-loggen ved hver request
• Ingen direkte state-mutasjon - kun nye events

Event-Typer

Grunnlag (TE sender, BH responderer)

Vederlag (TE sender krav, BH responderer)

Frist (TE sender krav, BH responderer)

Forsering (§33.8)

Endringsordre (§31.3)

System-Events

Spor-Status

Hvert spor har en status som endres basert på events:

IKKE_RELEVANT → UTKAST → SENDT → UNDER_BEHANDLING → GODKJENT/AVSLÅTT/DELVIS_GODKJENT
                                       ↓                    ↓
                                UNDER_FORHANDLING      TRUKKET
                                       ↓
                                    LAAST

Statuser:

• UNDER_FORHANDLING - BH har avslått/delvis godkjent, forhandling pågår
• LAAST - Grunnlag låst etter godkjenning

Data-Strukturer

SakEvent (Base)

class SakEvent:
    event_id: str           # Unik ID
    sak_id: str             # Hvilken sak
    event_type: EventType   # Type hendelse
    tidsstempel: datetime   # Når (UTC)
    aktor: str              # Hvem
    aktor_rolle: "TE" | "BH"
    kommentar: Optional[str]
    refererer_til_event_id: Optional[str]  # For responser

SakState (Projeksjon)

class SakState:
    sak_id: str
    sakstittel: str
    sakstype: SaksType                           # standard/forsering/endringsordre
    grunnlag: GrunnlagTilstand
    vederlag: VederlagTilstand
    frist: FristTilstand
    relaterte_saker: List[SakRelasjon]
    forsering_data: Optional[ForseringData]      # Kun for sakstype=forsering
    endringsordre_data: Optional[EndringsordreData]  # Kun for sakstype=endringsordre
    opprettet: Optional[datetime]
    siste_aktivitet: Optional[datetime]

Frontend/Backend Synkronisering

KRITISK: Typer må matche mellom frontend og backend!

Bruk python scripts/check_drift.py for å verifisere synkronisering.

API Flyt

Sende event

POST /api/events
{
  "sak_id": "SAK-001",
  "event_type": "grunnlag_opprettet",
  "aktor": "Ola Nordmann",
  "aktor_rolle": "TE",
  "data": { ... }
}

Hente state

GET /api/cases/{sak_id}/state
→ Returns: SakState (projisert fra alle events)

Regler og Validering

Rekkefølge-regler

• Kan ikke sende responsgrunnlag før grunnlagopprettet finnes
• Kan ikke sende vederlagkravsendt på trukket grunnlag
• BH kan bare respondere på events fra TE og vice versa

Forretningsregler

Se backend/services/business_rules.py for komplett liste.

Vanlige oppgaver

Legge til ny event-type

1. Legg til i EventType enum i backend/models/events.py
2. Opprett data-klasse hvis nødvendig
3. Legg til i AnyEvent union type
4. Oppdater src/types/timeline.ts (frontend)
5. Oppdater state-projeksjon i timeline_service.py
6. Kjør python scripts/check_drift.py for å verifisere

Endre state-modell

1. Oppdater Pydantic-modell i backend/models/sak_state.py
2. Oppdater TypeScript interface i src/types/timeline.ts
3. Oppdater projeksjon i backend/services/timeline_service.py
4. Kjør python scripts/state_drift.py for å verifisere