Sist endret: 16. juli 2026

Arkitekturmønstre i Resource Registry

Mønstre for ressursmetadata, policyer, tilgangslister og eierskap i Resource Registry.

Resource Registry forvalter metadata og sikkerhetsrelaterte koblinger for ressurser. Koden kombinerer klassisk lagdeling med mer eksplisitte aggregater for tilgangslister.

Tjenestelag over repositories

Controllere bruker kjernetjenester, som igjen avhenger av repositorygrensesnitt for ressurser, policyer og tilgangslister.

Fordeler: API-, domenelogikk og lagring kan endres og prøves separat. Ulemper: tynne lag kan gi mye videresending, mens store tjenester kan samle for mange regler.

Aggregater med hendelseshåndtering

Persistenslaget har generelle grenser for aggregater og aggregathendelser. Tilstandsendringer kan dermed behandles samlet rundt en konsistensgrense.

Fordeler: regler og hendelser knyttes til samme endring, og lagringen får en tydelig enhet. Ulemper: indirekte hendelsesflyt er vanskeligere å følge, og aggregater som blir store, gir samtidighetsproblemer.

Eksplisitt eierskapsautorisasjon

En egen ASP.NET Core-autorisasjonshåndterer kontrollerer om aktøren eier ressursen. En leverandør finner ressurseieren, og særskilte scopes behandles i en egen håndterer.

Fordeler: eierskapsregelen kan gjenbrukes deklarativt på endepunkter. Ulemper: flere håndterere kan gi uoversiktlig samspill, og feil i eieroppslaget påvirker alle beskyttede operasjoner.

Tilgangslister som eget deldomene

Tilgangslister har egne API-er, tjenestegrense og repository. Medlemskap og selve listen behandles som beslektede, men separate ressurser.

Fordeler: reglene for lister isoleres fra generell ressursmetadata. Ulemper: konsistens mellom liste, medlemskap og ressurs må sikres på tvers av operasjoner.

Resource Registry er planlagt flyttet inn i det midlertidige autorisasjonsrepoet. Mønstrene beskriver dagens kode; commitlåste lenker gjør analysens kilde eksplisitt når flyttingen skjer.