Domener

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:

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:

# 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 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.