---
title: Domener
description: Organiser Architecture Decision Records etter domene i Archgate. Grupper ADR-er etter arkitektur, testing, sikkerhet eller enhver egendefinert kategori for målrettet styring.
---

Domener er kategorier som grupperer relaterte ADR-er. Hver ADR tilhører nøyaktig ett domene, og domenet bestemmer prefikset som brukes i ADR-ens identifikator.

## Innebygde domener

Archgate leveres med fem innebygde domener. Hvert har et kort prefiks som vises i starten av hver ADR-ID i det domenet.

| Domene         | Prefiks | Brukes til                                            |
| -------------- | ------- | ----------------------------------------------------- |
| `backend`      | `BE`    | Server-side-logikk, API-er, databaser, tjenester      |
| `frontend`     | `FE`    | UI-komponenter, klient-side-logikk, stilmønstre       |
| `data`         | `DATA`  | Datamodeller, skjemaer, pipelines, lagringsstrategier |
| `architecture` | `ARCH`  | Tverrgående arkitekturbeslutninger                    |
| `general`      | `GEN`   | Generelle prosjektkonvensjoner og arbeidsflyter       |

For eksempel vil den tredje backend-ADR-en ha ID-en `BE-003`, og den første frontend-ADR-en vil være `FE-001`.

## Hvordan domener brukes

### ADR-identifikasjon

Domeneprefikset er bakt inn i hvert ADR-s `id`-felt. Når du kjører `archgate adr create` og velger et domene, bestemmer CLI-en automatisk neste tilgjengelige sekvensnummer for det domenets prefiks. Et arkitekturdomene med to eksisterende ADR-er (`ARCH-001`, `ARCH-002`) vil tildele `ARCH-003` til den neste.

Filnavnet speiler ID-en:

```
ARCH-003-dependency-policy.md
ARCH-003-dependency-policy.rules.ts
```

### Filtrering

Kommandoen `archgate adr list` støtter flagget `--domain` for å vise kun ADR-er fra et bestemt domene:

```bash
archgate adr list --domain backend
archgate adr list --domain architecture
```

Dette er nyttig i store prosjekter der mange ADR-er spenner over flere ansvarsområder. Filtrering etter domene lar deg fokusere på beslutningene som er relevante for ditt nåværende arbeid.

### AI-agentkontekst

Kommandoen `archgate review-context` grupperer endrede filer etter domene når den gir kontekst til AI-agenter. Når en agent skal skrive kode, mottar den bare ADR-briefingene som er relevante for domenene endringene berører, i stedet for det fullstendige settet av alle ADR-er. Denne avgrensningen reduserer støy og hjelper agenter å fokusere på begrensningene som faktisk gjelder.

### Avgrenset validering

Selv om domener i seg selv ikke begrenser hvilke filer en regel kan sjekke (det er jobben til `files`-globen i ADR frontmatteren), gir domener en logisk gruppering som hjelper team å organisere styringen sin. Et backend-team kan gjennomgå alle `BE-*`-ADR-er for å forstå sine begrensninger, mens frontend-teamet fokuserer på `FE-*`.

## Når du bør bruke hvilket domene

### backend

Bruk for beslutninger om server-side-kode: API-designmønstre, databasetilgangskonvensjoner, autentiseringsflyter, tjeneste-til-tjeneste-kommunikasjon, køhåndtering og mønster for bakgrunnsjobber.

**Eksempel-ADR-er:** API-responskonvoluttformat, databasemigreringsstrategi, feilkodetaksonomi.

### frontend

Bruk for beslutninger om klient-side-kode: komponentstruktur, tilstandshåndteringsmønstre, stilingsmetoder, tilgjengelighetskrav og valg av byggeverktøy.

**Eksempel-ADR-er:** Komponentfilstruktur, CSS-metodikk, skjemavalideringsmønster.

### data

Bruk for beslutninger om data: skjemadesign, datapipeline-konvensjoner, valg av lagringsmotor, serialiseringsformater og datavalideringsstrategier.

**Eksempel-ADR-er:** Hendelseskjemaversionering, databasenavnekonvensjoner, retningslinjer for dataoppbevaring.

### architecture

Bruk for tverrgående beslutninger som spenner over flere domener eller påvirker prosjektets overordnede struktur. Dette er beslutninger som backend-, frontend- og datateam alle må følge.

**Eksempel-ADR-er:** Kommandostruktur, feilhåndteringskonvensjoner, avhengighetsforvaltningspolicy, testestandarder.

### general

Bruk for prosjektomfattende konvensjoner som ikke passer godt inn i et teknisk domene: kodegjennomgangsprosesser, formater for commit-meldinger, dokumentasjonsstandarder og onboarding-praksis.

**Eksempel-ADR-er:** Commit-meldingsformat, PR-beskrivelsemal, dokumentasjonskrav.

## Velge riktig domene

Når du bestemmer hvilket domene en ADR tilhører, tenk på hvem som må følge den:

- Hvis bare backend-utviklere trenger å følge den, bruk `backend`.
- Hvis bare frontend-utviklere trenger å følge den, bruk `frontend`.
- Hvis den gjelder spesifikt datamodellering eller pipelines, bruk `data`.
- Hvis den gjelder på tvers av flere tekniske domener, bruk `architecture`.
- Hvis det er en prosess eller konvensjon snarere enn en teknisk beslutning, bruk `general`.

Når du er i tvil mellom `architecture` og et spesifikt domene, foretrekk det mer spesifikke domenet. Reserver `architecture` for beslutninger som genuint krysser grenser.

## Egendefinerte domener

Når de fem innebygde domenene virkelig ikke passer for en kategori av beslutninger -- for eksempel `security`, `ml-ops` eller `compliance` -- kan du registrere et egendefinert domene via CLI-en:

```bash
# Se hva som for øyeblikket er gjenkjent i dette prosjektet
archgate adr domain list

# Registrer et nytt domene med ID-prefiks
archgate adr domain add security SEC

# Fjern et egendefinert domene (innebygde kan ikke fjernes)
archgate adr domain remove security
```

Egendefinerte domene-til-prefiks-tilordninger lagres i [`.archgate/config.json`](/reference/configuration/) og slås sammen med de innebygde ved lesing. Et registrert egendefinert domene oppfører seg nøyaktig som et innebygd: `archgate adr create --domain security` genererer automatisk ID-er som `SEC-001`, og `archgate adr list --domain security` filtrerer til disse ADR-ene.

### Navneregler

- **Navn** -- kebab-case med små bokstaver, 2--32 tegn (f.eks. `security`, `ml-ops`, `compliance`).
- **Prefiks** -- store bokstaver, sifre eller understreker, 2--10 tegn (f.eks. `SEC`, `MLOPS`, `COMP`).
- Egendefinerte navn og prefikser kan ikke kollidere med innebygde eller andre egendefinerte oppføringer.

### Når du bør foretrekke et innebygd

De fem innebygde domenene er bevisst opinionerte. Før du registrerer et egendefinert domene, sjekk om beslutningen kan plasseres under et eksisterende:

- En beslutning om autentiseringsmellomvare passer vanligvis under `backend`, selv om motivasjonen er sikkerhet.
- En beslutning om skjemaversionering passer vanligvis under `data`, selv om motivasjonen er samsvar.
- En beslutning som spenner over flere tekniske områder passer vanligvis under `architecture`.

Bruk et egendefinert domene bare når ingen av de innebygde passer -- for eksempel når du har et dedikert team eller et samsvarregime som trenger sin egen styringsflate.

### Veiledning for AI-agenter

Når du bruker Archgate-editorpluginen til å opprette ADR-er, er agentene instruert til å foretrekke de innebygde domenene og spørre før de introduserer et egendefinert. De viser den samlede listen via `archgate adr domain list` og registrerer bare et nytt domene etter å ha bekreftet med deg at ingen innebygde passer.
