Gå til hovedinnhold

Domener og kontekstkart for FS

Her finner du hvilke områder vi har systemstøtte før i FS (domener). Vi skiller mellom kjernedomener og støttedomener. Kontekstkartet viser såkalte bounded contexts og deres relasjoner i FS, og visualiserer innholdet basert på Domain-Driven Design (DDD) prinsipper.

Kjernedomener​

Disse domenene representerer det FS skiller seg ut og leverer støtte til innen høyere akademisk og yrkesfaglig utdanning.

Person​

Personidentitet og grunnleggende persondata, inkludert integrasjon mot folkeregisteret og kontakt- og reservasjonsregisteret. Konsumeres av alle andre kjernedomener, men eies og forvaltes her. Entiteter i andre domener refererer til person, men muterer den ikke. Eier også læresteduavhengige data som samtykker og kontaktopplysninger – selv om disse kan bekreftes i forbindelse med et studentforhold, tilhører de personen, ikke lærestedet.

Utdanning​

Emner, studieprogram og kurs, samt utdanningstilbud og oppbygning – definisjon av hva som tilbys, når, hvor og av hvem, samt hvordan utdanning er strukturert. Eier den grunnleggende definisjonen av utdanningen, utdanningstilbudet og eventuelt strukturen som andre domener konsumerer.

Organisasjon​

Organisasjoner, herunder læresteder og andre typer, samt organisasjonsenheter som avdelinger og fakulteter ved ett lærested, samt studiesteder (campus) Skilles fra utdanning fordi endringstakt og organisatorisk ansvar er ulikt.

Opptak​

Opptaksprosessen i FS – søknad, rangering og tildeling av plass. Deles i to eksplisitte kontekster som deler kjernelogikk og datamodell, men har ulike regler, aktører og livssyklus:

  • Eksternt opptak – opptak til studieprogram (inkl. i prinsippet også innreisende utvekslingsstudenter), emner, kurs som er åpne for søkere som ikke har studierett fra før av, med kvoter, tilbud om studieplass.

  • Internt opptak – emneoppmelding og tildeling av plass på undervisning, forhåndsopptak til obligatoriske emner, opptak til utreisende utveksling og praksis. Orkestreres fra studieforhold, men opptakslogikken eies her.

Opptaksdomenet eier sin egen representasjon av utdanningstilbudet (Søknadsalternativ ?), beriket med kvoter, plasser og frister, koblet til utdanningsdomenet via ID.

Studentforhold​

Relasjonen mellom en person og et studieprogram ved et lærested – fra immatrikulering/inntak/tildeling av studierett til fullføring eller frafall. Inkluderer:

  • Studierettigheter og progresjon gjennom studieløpet
  • Løpende studieadministrative oppgaver knyttet til det konkrete studieforholdet, som betaling av utdanningsavgifter og bekreftelse på reglementer
  • Permisjoner og avbrudd
  • Saksbehandling av studenter fra lærestedets side
  • Studentens egen selvbetjening av studieadministrative oppgaver

Merk: samtykker og bekreftelse av kontaktopplysninger eies av Person, da disse er læresteduavhengige og knyttet til personen, ikke studieforholdet.

Konsumerer fra person, utdanning og opptak. Hypotese: Orkestrerer internt opptak ved å initiere opptaksprosesser for emner, utveksling og praksis. Produserer grunnlaget som vurdering og resultater bygger på.

Vurdering og resultater​

Eksamen, sensur, karakterer, kvalifikasjoner og vitnemål. Kvalifikasjoner forstås her som sammenstillinger av resultater, f.eks. vitnemål.

Støttedomener​

Nødvendige for at systemet fungerer, men ikke særegne for FS. Bør ikke blandes inn i kjernedomene-modellene.

Kommunikasjon​

Meldinger og varsler rettet mot brukere, søkere og studenter. Tre kapabiliteter:

  • Systemmeldinger – releasemeldinger og driftsvarsler som vises i grensesnittet, typisk én-til-mange
  • Varsler – hendelsesdrevne, personaliserte meldinger knyttet til en persons sak eller status (f.eks. tilbud om studieplass, publisert sensur), initiert av systemet eller saksbehandlere
  • Utgående kanallevering – e-post, SMS og fremtidig nasjonal meldingstjeneste (jf. DPI/Altinn)

Kommunikasjon konsumerer hendelser fra kjernedomener (opptak, vurdering, person), men eier ingen av dem. God kandidat for hendelsesdrevet arkitektur. Forretningskritisk støttedomene – feil kommunikasjon i opptak eller eksamen har store konsekvenser.

Brukeradministrasjon og tilgangsstyring​

Autentisering, autorisasjon, rolletildeling og rollestyring. Nødvendig, men ikke særegent for FS.

Systeminnstillinger​

Konfigurasjon og infrastruktur. Lav prioritet i modernisering, men må ha et tydelig hjem for å unngå at konfigurasjon forurenser kjernedomener.

Nøkkelprinsipper​

  • Eierskap følger livssyklus – en entitet eies av det domenet der den har sin primære livssyklus og forretningsmessige betydning. Andre domener konsumerer, ikke muterer.

  • Lokale representasjoner – der samme konsept opptrer i flere domener (f.eks. utdanningstilbud → opptakstilbud) har hvert domene sin egen representasjon med egne attributter, koblet via ID og eksplisitt oversettelse.

  • Eksplisitte kontekster fremfor usynlig deling – der kode og datamodell deles mellom kontekster (f.eks. eksternt og internt opptak) skal dette navngis og synliggjøres, ikke ligge implisitt.

  • Støttedomener har tydelig hjem – selv generiske domener må avgrenses, ellers forurenser de kjernemodellene.

Context Map Diagram​

PersonIdentitet · samtykker · kontaktoppl.[upstream]UtdanningEmner · studieprogram · tilbudOrganisasjonOrganisasjon · orgenheterOpptakEksternt opptakProgramopptak · kvoter · plasstild.Internt opptakEmneoppmelding · utveksling · praksis[shared kernel: opptakslogikk og datamodell]StudentforholdRettigheter · progresjon · selvbetjeningVurdering og resultaterEksamen · sensur · karakterer · vitnemålStøttedomenerKommunikasjonVarsler · meldinger · kanalerBrukeradm. og tilgangAutentisering · rollerSysteminnstillingerKonfigurasjon · infrastrukturDDDDACLU→Dorkestrert avU→DeventsPerson upstream (D = downstream)Konsumering (solid)Hendelsesdrevet (events)ACL = anticorruption layer · U→D = upstream/downstream · shared kernel = delt modell

Tegnforklaring​

Relasjonsmønstre i diagrammet​

  • U/D (Upstream/Downstream): En domene (upstream) definerer grensesnittet som andre (downstream) må tilpasse seg til
  • ACL (Anticorruption Layer): Et oversettingslag som beskytter et domene fra et annets modell
  • Shared Kernel: To kontekster deler eksplisitt kode og datamodell
  • Customer/Supplier: Ett domene bestiller tjenester fra et annet
  • Orchestration: Ett domene orkestrerer/initierer prosesser i et annet
  • Events: Hendelsesdrevet kommunikasjon mellom domener
  • Consumer: Ett domene konsumerer data fra et annet

Farger i diagrammet​

  • Grønn (#c8e6c9): Kjernedomener - det som gjør FS unikt
  • Blå (#e1f5fe): Støttedomener - nødvendige men ikke særegne