Dataeierskap som
grunnlag for
applikasjonsutvikling
Make Data Smart
Trondheim 2022
Mufrid Krilic
Domain-Driven Design Coach, CoWork
Slide 2
Slide 2 text
@mufridk
CoWork –
Ingen ledere men
fullt av ledelse
• Tight Loose Tight – TLT
• Strategisk og smidig ledelse
• Domain-Driven Design
• Taktisk og operativ produkt- og
teknologiledelse
Slide 3
Slide 3 text
Bok anbefaling #1
Slide 4
Slide 4 text
@mufridk
Læringsmål for neste ~30 min
• Ulike perspektiver for applikasjonsutvikling og data analyse
• Domain Storytelling
• metodikk for å forstå domene og forretning
• Etablere dataeierskap med Domain-Driven Design
Slide 5
Slide 5 text
Om ulike perspektiver
Applikasjonsutvikling og data analyse
Slide 6
Slide 6 text
Ulike perspektiver
• Applikasjonsutvikling
• Data analyse
• Operasjonelle data
• Analytiske data
Slide 7
Slide 7 text
@mufridk
Ulik organisering
• Team for data analyse og
rapportering
• Atskilt fra applikasjonsutviklingen
• Forankret i ekte behov for egen
datamodell for analytiske data
• Datamodellen lagd for
applikasjonsbehov er ofte ikke
tilstrekkelig
Slide 8
Slide 8 text
Kan vi redusere
gapet?
• Kan vi ha et annet utgangspunkt?
• Modellering av applikasjonsdata
Slide 9
Slide 9 text
Bok anbefaling #2
Slide 10
Slide 10 text
Etablerte
domenegrenser!
• Forutsetning for Data Mesh!
• «domain-oriented decentralized data
ownership and architecture»
Slide 11
Slide 11 text
Use Case
Gruppebehandling - Oppmøteregistrering
Slide 12
Slide 12 text
@mufridk
▪ For pasienter med identiske diagnoser kan felles
behandling i grupper gi en god effekt
▪ Eksempler
• Psykiatri
• Samtalegrupper
• Somatikk
• Bassengtrening
Domene: Gruppebehandling i sykehus
Slide 13
Slide 13 text
@mufridk
Slide 14
Slide 14 text
@mufridk
Slide 15
Slide 15 text
@mufridk
Slide 16
Slide 16 text
@mufridk
Slide 17
Slide 17 text
@mufridk
Tegnet med egon.io
Slide 18
Slide 18 text
Bok anbefaling #3
Slide 19
Slide 19 text
Dataeierskap og
modellering
Om ulike tilnærminger til applikasjonsutvikling
Slide 20
Slide 20 text
@mufridk
Dataeierskap
• Et domenebegrep er definert som et
sett med data-egenskaper
Slide 21
Slide 21 text
@mufridk
Funksjonell
dekomponering
• Avgrensninger i systemet etter
funksjonene som en bruker trenger
for å gjøre jobben sin
• Klassisk tilnærming
• Subdomene = Funksjon
Slide 22
Slide 22 text
@mufridk
Gruppebehandling i sykehus
Slide 23
Slide 23 text
@mufridk
Domenemodell
Slide 24
Slide 24 text
Dataeierskap –
funksjonell dekomponering
• «Gruppe» for ulike funksjoner
• Behandlere
• Pasienter som deltar i behandlingen
• Oppmøtetidspunkter
• Lokasjon
• Hvem som (ikke) møtte opp
• Hvem som kansellerte
• Hvem har frikort
• Hvordan motta faktura
• Hva er egenandel ut fra diagnosegruppe
Slide 25
Slide 25 text
@mufridk
Rollebasert
dekomponering
• Avgrensninger i systemet ut fra
hvilke roller som utfører ulike
funksjoner
• Tillater for mer oppgaveorientert
applikasjon
• Subdomene = Rollebasert funksjon
Slide 26
Slide 26 text
@mufridk
Slide 27
Slide 27 text
@mufridk
Domenemodell
Slide 28
Slide 28 text
@mufridk
Dataeierskap
- rollebasert dekomponering
«Gruppe» planleggingskontekst
• Behandlere
• Pasienter som deltar i
behandlingen
• Oppmøtetidspunkter
• Lokasjon
«Gruppe» oppmøtekontekst
• Hvem som (ikke) møtte opp
• Hvem som kansellerte
• Hvem har frikort
• Hvordan motta faktura
• Hva er egenandel ut fra
diagnosegruppe
Slide 29
Slide 29 text
@mufridk
Tids- og
rollebasert
dekomponering
• Avgrensninger i systemet ut fra
hvilke roller utfører ulike funksjoner
på ulike tidspunkter
• Tillater for brukerkontekst-orientert
applikasjon
• Subdomene = Rollebasert funksjon i
en tidskontekst
Slide 30
Slide 30 text
@mufridk
Slide 31
Slide 31 text
@mufridk
Domenemodell
Slide 32
Slide 32 text
@mufridk
Dataeierskap
- tids- og rollebasert dekomponering
«Gruppe» planleggingskontekst
• Behandlere
• Pasienter som deltar i behandlingen
• Oppmøtetidspunkter
• Lokasjon
«Gruppe» økonomikontekst
• Hvem har frikort
• Hvordan motta faktura
• Hva er egenandel ut fra
diagnosegruppe
«Gruppe» oppmøtekontekst
• Hvem som (ikke) møtte opp
• Hvem som kansellerte
Slide 33
Slide 33 text
@mufridk
Dekomponering
etter
forretningstjenester
• Avgrensninger i systemet etter
tjenester som forretningen tilbyr
sine kunder
• Subdomene = Forretningstjeneste
• Subdomene ≠ Funksjon
• Utgangspunkt for produktarkitektur
Forretningstjeneste aka Business Capability
Slide 34
Slide 34 text
@mufridk
Slide 35
Slide 35 text
@mufridk
Domenemodell
Slide 36
Slide 36 text
@mufridk
Dataeierskap
- forretningstjenester dekomponering
«Gruppe» psykiatri tjeneste
• Psykolog og/eller psykiater som
behandlere
• Diagnose
• Psykiatrivedtak
• Pasienter
• Oppmøtetidspunkter
«Gruppe» somatikk tjeneste
• Lege som behandler
• Diagnose
• Oppmøtelokasjon utenfor sykehuset
• Pasienter
• Oppmøtetidspunkter
Slide 37
Slide 37 text
@mufridk
Flere eksempler på
forretningstjenester
Helsedomenet:
• Nevrokirurgi
• Føden
• Blodbanken
Slide 38
Slide 38 text
@mufridk
Flere eksempler på
forretningstjenester
Forsikringsdomenet:
• Husforsikring
• Bilforsikring
• Personforsikring
Forretningstjenester istedenfor
funksjoner
Slide 39
Slide 39 text
Om funksjonell
dekomponering
• Brukerbehovene blir gjemt bak
funksjoner!
• Svært lite bærekraftig modell !!
Slide 40
Slide 40 text
No content
Slide 41
Slide 41 text
@mufridk
Språk som
verktøy
• Ett og samme domenebegrep i ulike
subdomener er definert med ulik,
evt. delvis overlappende sett med
egenskaper
• Bruk domenespråket til å finne
passende nivå for dekomponering
Slide 42
Slide 42 text
Bok anbefaling #4
Slide 43
Slide 43 text
Domain-Driven Design
Om prinsippene for strategisk DDD
Slide 44
Slide 44 text
Kjernedomenet
• Det som skiller deg fra dine
konkurrenter
• “Ikke alle deler av et system vil bli
designet på en like god måte”
• Generiske subdomener
• Støtte-subdomener
• Supporting Subdomain
Slide 45
Slide 45 text
Problemrommet
og
løsningsrommet
Problemrommet
• Domeneanalyse for å oppdage
naturlige Subdomener
Løsningsrommet
• Modellere applikasjon på en
tilsvarende måte for å etablere
Avgrensede Kontekster
• Bounded Contexts
Slide 46
Slide 46 text
Språklige grenser
Ubiquitous Language
• Omforent språk
• Det samme språket overalt
• Samtaler
• Dokumentasjon
• Kode
Slide 47
Slide 47 text
De to pilarene av
DDD
1. Omforent språk
2. Avgrensede kontekster
• Avgrensede kontekster (Bounded
Contexts) i applikasjonen defineres
av språklige grenser
• Kontekst er en del av applikasjonen
der et domenebegrep er entydig
Slide 48
Slide 48 text
Tverrfaglig
samarbeid
• Lage programvare som er så nært
som mulig til det domeneeksperter
hadde lagd om de hadde vært
utviklere
• En utforskningsprosess der alle ,
inkl. domeneeksperter faktisk kan
lære enda mer om domene
Slide 49
Slide 49 text
Strategisk DDD
• Fokusere på kjernedomenet
• Problem- og løsningsrommet
• Subdomener og Bounded Contexts
• Språklige grensene
• Omforent språk
• Tverrfaglig samarbeid mellom
domeneeksperter og produktteam
Slide 50
Slide 50 text
Oppsummering og takeaways
▪ Respektere og forene ulike behovene for
applikasjonsutvikling og data analyse
– Data Mesh
▪ Ulike tilnærminger til modellering i
applikasjonsutviklingen
– Unngå funksjonell dekomponering
▪ Etablere dataeierskap med Domain-Driven Design
Ella Fitzegerald –
«They Cant’t Take That Away From Me»
Slide 51
Slide 51 text
Takk for meg!
• https://www.linkedin.com/in/mufrid/