Domenedrevet design: Mestring av avgrensede kontekster for skalerbar programvare

Domenedrevet design (DDD) er en kraftfull tilnærming for å takle komplekse programvareprosjekter ved å fokusere på kjerneområdet. I hjertet av DDD ligger konseptet Avgrensede kontekster. Å forstå og effektivt bruke avgrensede kontekster er avgjørende for å bygge skalerbare, vedlikeholdbare og til syvende og sist vellykkede programvaresystemer. Denne omfattende guiden vil fordype seg i intrikatene ved avgrensede kontekster, og utforske både de strategiske og taktiske mønstrene som er involvert.

Hva er en avgrenset kontekst?

En avgrenset kontekst er en semantisk grense innenfor et programvaresystem som definerer anvendeligheten av en bestemt domenemodell. Tenk på det som et tydelig definert omfang der spesifikke termer og konsepter har en konsekvent og utvetydig betydning. Innenfor en avgrenset kontekst er allestedsnærværende språk, den delte ordforrådet som brukes av utviklere og domeneeksperter, godt definert og konsistent. Utenfor denne grensen kan de samme termene ha forskjellige betydninger eller ikke være relevante i det hele tatt.

I hovedsak erkjenner en avgrenset kontekst at en enkelt, monolitisk domenemodell ofte er upraktisk, om ikke umulig, å lage for komplekse systemer. I stedet anbefaler DDD å dele problemet inn i mindre, mer håndterbare kontekster, hver med sin egen modell og allestedsnærværende språk. Denne nedbrytingen bidrar til å håndtere kompleksitet, forbedre samarbeidet og tillate mer fleksibel og uavhengig utvikling.

Hvorfor bruke avgrensede kontekster?

Bruk av avgrensede kontekster gir mange fordeler i programvareutvikling:

• Redusert kompleksitet: Ved å dele et stort domene inn i mindre, mer håndterbare kontekster, reduserer du den generelle kompleksiteten i systemet. Hver kontekst kan forstås og vedlikeholdes lettere.
• Forbedret samarbeid: Avgrensede kontekster letter bedre kommunikasjon mellom utviklere og domeneeksperter. Det allestedsnærværende språket sikrer at alle snakker samme språk innenfor en bestemt kontekst.
• Uavhengig utvikling: Team kan jobbe uavhengig av hverandre på forskjellige avgrensede kontekster uten å tråkke hverandre på tærne. Dette gir raskere utviklingssykluser og økt smidighet.
• Fleksibilitet og skalerbarhet: Avgrensede kontekster gjør det mulig å utvikle forskjellige deler av systemet uavhengig. Du kan skalere spesifikke kontekster basert på deres individuelle behov.
• Forbedret kodekvalitet: Å fokusere på et spesifikt domene innenfor en avgrenset kontekst fører til renere, mer vedlikeholdbar kode.
• Justering med virksomheten: Avgrensede kontekster justeres ofte med spesifikke forretningsfunksjoner eller avdelinger, noe som gjør det lettere å kartlegge programvare til forretningsbehov.

Strategisk DDD: Identifisere avgrensede kontekster

Å identifisere avgrensede kontekster er en viktig del av den strategiske designfasen i DDD. Det innebærer å forstå domenet, identifisere viktige forretningsfunksjoner og definere grensene for hver kontekst. Her er en trinnvis tilnærming:

1. Domeneutforskning: Begynn med å utforske problemet grundig. Snakk med domeneeksperter, gjennomgå eksisterende dokumentasjon og forstå de forskjellige forretningsprosessene som er involvert.
2. Identifiser forretningsfunksjoner: Identifiser kjerneforretningsfunksjonene som programvaresystemet trenger å støtte. Disse funksjonene representerer de essensielle funksjonene som virksomheten utfører.
3. Se etter semantiske grenser: Se etter områder der betydningen av termer endres eller der forskjellige forretningsregler gjelder. Disse grensene indikerer ofte potensielle avgrensede kontekster.
4. Vurder organisasjonsstruktur: Selskapets organisasjonsstruktur kan ofte gi ledetråder om potensielle avgrensede kontekster. Ulike avdelinger eller team kan være ansvarlige for forskjellige områder av domenet. Conways lov, som sier at "organisasjoner som designer systemer er tvunget til å produsere design som er kopier av kommunikasjonsstrukturene til disse organisasjonene", er svært relevant her.
5. Tegn et kontekstkart: Lag et kontekstkart for å visualisere de forskjellige avgrensede kontekstene og deres forhold. Dette kartet vil hjelpe deg med å forstå hvordan de forskjellige kontekstene samhandler med hverandre.

Eksempel: Et e-handelssystem

Tenk på et stort e-handelssystem. Det kan inneholde flere avgrensede kontekster, for eksempel:

• Produktkatalog: Ansvarlig for å administrere produktinformasjon, kategorier og attributter. Det allestedsnærværende språket inkluderer termer som "produkt", "kategori", "SKU" og "attributt".
• Ordrebehandling: Ansvarlig for å behandle bestillinger, administrere forsendelser og håndtere returer. Det allestedsnærværende språket inkluderer termer som "ordre", "forsendelse", "faktura" og "betaling".
• Kundeadministrasjon: Ansvarlig for å administrere kundekontoer, profiler og preferanser. Det allestedsnærværende språket inkluderer termer som "kunde", "adresse", "lojalitetsprogram" og "kontaktinformasjon".
• Lagerstyring: Ansvarlig for å spore lagernivåer og administrere lagringssteder. Det allestedsnærværende språket inkluderer termer som "lagernivå", "sted", "bestillingspunkt" og "leverandør".
• Betalingsbehandling: Ansvarlig for å behandle betalinger sikkert og håndtere refusjoner. Det allestedsnærværende språket inkluderer termer som "transaksjon", "autorisasjon", "oppgjør" og "kortdetaljer".
• Anbefalingsmotor: Ansvarlig for å gi produktanbefalinger til kunder basert på deres nettleserhistorikk og kjøpsatferd. Det allestedsnærværende språket inkluderer termer som "anbefaling", "algoritme", "brukerprofil" og "produkttilknytning".

Hver av disse avgrensede kontekstene har sin egen modell og allestedsnærværende språk. For eksempel kan termen "produkt" ha forskjellige betydninger i Produktkatalogen og Ordrebehandlingskontekstene. I Produktkatalogen kan det referere til de detaljerte spesifikasjonene til et produkt, mens det i Ordrebehandling kan det rett og slett referere til varen som kjøpes.

Kontekstkart: Visualisere forholdet mellom avgrensede kontekster

Et kontekstkart er et diagram som visuelt representerer de forskjellige avgrensede kontekstene i et system og deres forhold. Det er et viktig verktøy for å forstå hvordan de forskjellige kontekstene samhandler og for å ta informerte beslutninger om integrasjonsstrategier. Et kontekstkart går ikke inn i de interne detaljene i hver kontekst, men fokuserer heller på samspillet mellom dem.

Kontekstkart bruker vanligvis forskjellige notasjoner for å representere de forskjellige typene forhold mellom avgrensede kontekster. Disse forholdene blir ofte referert til som integrasjonsmønstre.

Taktisk DDD: Integrasjonsmønstre

Når du har identifisert dine avgrensede kontekster og opprettet et kontekstkart, må du bestemme hvordan disse kontekstene skal samhandle med hverandre. Det er her den taktiske designfasen kommer inn. Taktisk DDD fokuserer på de spesifikke integrasjonsmønstrene du vil bruke for å koble dine avgrensede kontekster.

Her er noen vanlige integrasjonsmønstre:

• Delt kjerne: To eller flere avgrensede kontekster deler en felles modell eller kode. Dette er et risikabelt mønster, da endringer i den delte kjernen kan påvirke alle kontekster som er avhengige av den. Bruk dette mønsteret sparsomt og bare når den delte modellen er stabil og godt definert. For eksempel kan flere tjenester innen en finansinstitusjon dele et kjernebibliotek for valutaberegninger.
• Kunde-Leverandør: En avgrenset kontekst (Kunden) er avhengig av en annen avgrenset kontekst (Leverandøren). Kunden former aktivt Leverandørens modell for å dekke sine behov. Dette mønsteret er nyttig når en kontekst har et sterkt behov for å påvirke den andre. Et markedsføringskampanjestyringssystem (Kunde) kan i stor grad påvirke utviklingen av en kundedataplattform (Leverandør).
• Konformist: En avgrenset kontekst (Konformisten) bruker bare modellen til en annen avgrenset kontekst (Oppstrøms). Konformisten har ingen innflytelse over Oppstrøms modell og må tilpasse seg endringene. Dette mønsteret brukes ofte ved integrering med eldre systemer eller tredjepartstjenester. En liten salgsapplikasjon kan rett og slett tilpasse seg datamodellen levert av et stort, etablert CRM-system.
• Anti-korrupsjonslag (ACL): Et abstraksjonslag som ligger mellom to avgrensede kontekster, og oversetter mellom modellene deres. Dette mønsteret beskytter nedstrømskonteksten mot endringer i oppstrømskonteksten. Dette er et viktig mønster når du har med eldre systemer eller tredjepartstjenester som du ikke kan kontrollere. For eksempel, ved integrasjon med et eldre lønnssystem, kan en ACL oversette det eldre dataformatet til et format som er kompatibelt med HR-systemet.
• Separate veier: To avgrensede kontekster har ingen forhold til hverandre. De er helt uavhengige og kan utvikle seg uavhengig av hverandre. Dette mønsteret er nyttig når de to kontekstene er fundamentalt forskjellige og ikke har behov for å samhandle. Et internt utgiftspårningssystem for ansatte kan holdes helt atskilt fra den offentlige e-handelsplattformen.
• Åpen verts-tjeneste (OHS): En avgrenset kontekst publiserer et godt definert API som andre kontekster kan bruke for å få tilgang til funksjonaliteten. Dette mønsteret fremmer løs kobling og gir mer fleksibel integrasjon. API-et bør utformes med forbrukernes behov i tankene. En betalingsgatewaytjeneste (OHS) eksponerer et standardisert API som forskjellige e-handelsplattformer kan bruke for å behandle betalinger.
• Publisert språk: Den åpne verts-tjenesten bruker et godt definert og dokumentert språk (f.eks. XML, JSON) for å kommunisere med andre kontekster. Dette sikrer interoperabilitet og reduserer risikoen for feiltolkning. Dette mønsteret brukes ofte i forbindelse med mønsteret Åpen verts-tjeneste. Et forsyningskjedestyringssystem eksponerer data via et REST API ved hjelp av JSON Schema for å sikre klar og konsistent datautveksling.

Velge riktig integrasjonsmønster

Valget av integrasjonsmønster avhenger av flere faktorer, inkludert forholdet mellom de avgrensede kontekstene, stabiliteten i modellene deres og kontrollnivået du har over hver kontekst. Det er viktig å nøye vurdere avveiningene av hvert mønster før du tar en beslutning.

Vanlige fallgruver og antimønstre

Mens avgrensede kontekster kan være utrolig fordelaktige, er det også noen vanlige fallgruver å unngå:

• Stor søle av gjørme: Unnlatelse av å definere avgrensede kontekster riktig og ende opp med et monolitisk system som er vanskelig å forstå og vedlikeholde. Dette er det motsatte av hva DDD tar sikte på å oppnå.
• Utilsiktet kompleksitet: Innføring av unødvendig kompleksitet ved å lage for mange avgrensede kontekster eller ved å velge upassende integrasjonsmønstre.
• For tidlig optimalisering: Å prøve å optimalisere systemet for tidlig i prosessen før du fullt ut forstår domenet og forholdet mellom de avgrensede kontekstene.
• Ignorerer Conways lov: Unnlatelse av å justere de avgrensede kontekstene med selskapets organisasjonsstruktur, noe som fører til kommunikasjons- og koordineringsproblemer.
• Overdreven avhengighet av delt kjerne: Bruke mønsteret Delt kjerne for ofte, noe som fører til tett kobling og redusert fleksibilitet.

Avgrensede kontekster og mikrotjenester

Avgrensede kontekster brukes ofte som utgangspunkt for å designe mikrotjenester. Hver avgrenset kontekst kan implementeres som en egen mikrotjeneste, noe som gir mulighet for uavhengig utvikling, implementering og skalering. Det er imidlertid viktig å merke seg at en avgrenset kontekst ikke nødvendigvis må implementeres som en mikrotjeneste. Den kan også implementeres som en modul i en større applikasjon.

Når du bruker avgrensede kontekster med mikrotjenester, er det viktig å nøye vurdere kommunikasjonen mellom tjenestene. Vanlige kommunikasjonsmønstre inkluderer REST API-er, meldingskøer og hendelsesdrevne arkitekturer.

Praktiske eksempler fra hele verden

Bruken av avgrensede kontekster er universelt anvendelig, men detaljene vil variere avhengig av bransjen og konteksten.

• Global logistikk: Et multinasjonalt logistikkselskap kan ha separate avgrensede kontekster for *Forsendelsessporing* (håndtering av sanntidsoppdateringer om posisjon), *Tollbehandling* (som omhandler internasjonale forskrifter og dokumentasjon) og *Lagerstyring* (optimalisering av lagring og inventar). "Varen" som spores har svært forskjellige representasjoner i hver kontekst.
• Internasjonal bankvirksomhet: En global bank kan bruke avgrensede kontekster for *Banktjenester for privatkunder* (administrere individuelle kundekontoer), *Bedriftsbanktjenester* (håndtere forretningslån og transaksjoner) og *Investeringsbanktjenester* (som omhandler verdipapirer og handel). Definisjonen av "kunde" og "konto" vil variere betydelig på tvers av disse områdene, noe som gjenspeiler ulike forskrifter og forretningsbehov.
• Fler-språklig innholdsadministrasjon: En global nyhetsorganisasjon kan ha distinkte avgrensede kontekster for *Innholdsopprettelse* (forfatte og redigere artikler), *Oversettelsesadministrasjon* (håndtere lokalisering for forskjellige språk) og *Publisering* (distribuere innhold på tvers av forskjellige kanaler). Konseptet "artikkel" har forskjellige attributter avhengig av om det forfattes, oversettes eller publiseres.

Konklusjon

Avgrensede kontekster er et grunnleggende konsept i domenedrevet design. Ved å forstå og bruke avgrensede kontekster effektivt, kan du bygge komplekse, skalerbare og vedlikeholdbare programvaresystemer som er tilpasset forretningsbehov. Husk å nøye vurdere forholdet mellom dine avgrensede kontekster og velge de riktige integrasjonsmønstrene. Unngå vanlige fallgruver og anti-mønstre, så er du godt på vei til å mestre domenedrevet design.

Handlingsrettede innsikter

1. Begynn smått: Ikke prøv å definere alle dine avgrensede kontekster på en gang. Start med de viktigste områdene av domenet og iterer etter hvert som du lærer mer.
2. Samarbeid med domeneeksperter: Engasjer domeneeksperter gjennom hele prosessen for å sikre at dine avgrensede kontekster nøyaktig gjenspeiler forretningsdomenet.
3. Visualiser kontekstkartet ditt: Bruk et kontekstkart for å kommunisere forholdet mellom dine avgrensede kontekster til utviklingsteamet og interessentene.
4. Refaktor kontinuerlig: Ikke vær redd for å refaktorere dine avgrensede kontekster etter hvert som din forståelse av domenet utvikler seg.
5. Omfavn endring: Avgrensede kontekster er ikke hugget i stein. De bør tilpasses endrede forretningsbehov og teknologiske fremskritt.