Domain-driven design
Softwaremodeller udvikles ud fra forretningsområdet sammen med de mennesker, der kender dets regler.
Hvad er domain-driven design?
Domain-driven design, forkortet DDD, tager udgangspunkt i et forretningsområde ved modellering af software. Domænekyndige og udviklingsteamet afklarer sammen begreber, regler og sammenhænge. Et fælles sprog skal have samme betydning inden for en afgrænset forretningsmæssig sammenhæng. Forskellige sammenhænge kan kræve egne modeller; grænsen kaldes ofte Bounded Context.
I en opdigtet virksomhed betyder »ordre« en solgt ydelse for salgsteamet og et planlagt besøg for serviceteamet. Deltagerne beskriver begge betydninger og overleveringen i stedet for stiltiende at forudsætte én datamodel. Det kan give tydeligere softwaregrænser. DDD kræver dog hverken microservices eller en bestemt databasetype. Teknisk opdeling og drift af modeller er en yderligere arkitekturbeslutning.
Kilder
Relaterede begreber
- SoftwarearkitekturGrundlæggende beslutninger om et softwaresystems struktur, samspil og kvalitetsmål.
- Modulær monolitEn samlet udrullet applikation med udtrykkeligt afgrænsede indre moduler og grænseflader.
- Cache stampedeEt cache stampede opstår, når samtidige cache-misses starter den samme dyre beregning eller dataforespørgsel flere gange.
- BackpressureBackpressure tilpasser datastrømmen til modtagerens behandlingskapacitet gennem signaler om at sænke tempoet eller holde pause.
- Race conditionEt forkert resultat afhænger af tidsrækkefølgen i overlappende adgange.
- HukommelseslækHukommelse, der ikke længere behøves, holdes unødigt optaget under drift.
Artikler om emnet
Dit projekt med ASES
Beskriv dit projekt for os. Vi vender tilbage med en første vurdering.