1.
Dataeierskap som
grunnlag for
applikasjonsutvikling
Make Data Smart
Trondheim 2022
Mufrid Krilic
Domain-Driven Design Coach, CoWork

2.
@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

3.
Bok anbefaling #1

4.
@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

5.
Om ulike perspektiver
Applikasjonsutvikling og data analyse

6.
Ulike perspektiver
• Applikasjonsutvikling
• Data analyse
• Operasjonelle data
• Analytiske data

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

8.
Kan vi redusere
gapet?
• Kan vi ha et annet utgangspunkt?
• Modellering av applikasjonsdata

9.
Bok anbefaling #2

10.
Etablerte
domenegrenser!
• Forutsetning for Data Mesh!
• «domain-oriented decentralized data
ownership and architecture»

11.
Use Case
Gruppebehandling - Oppmøteregistrering

12.
@mufridk
 For pasienter med identiske diagnoser kan felles
behandling i grupper gi en god effekt
 Eksempler
• Psykiatri
• Samtalegrupper
• Somatikk
• Bassengtrening
Domene: Gruppebehandling i sykehus

13.
@mufridk

14.
@mufridk

15.
@mufridk

16.
@mufridk

17.
@mufridk
Tegnet med egon.io

18.
Bok anbefaling #3

19.
Dataeierskap og
modellering
Om ulike tilnærminger til applikasjonsutvikling

20.
@mufridk
Dataeierskap
• Et domenebegrep er definert som et
sett med data-egenskaper

21.
@mufridk
Funksjonell
dekomponering
• Avgrensninger i systemet etter
funksjonene som en bruker trenger
for å gjøre jobben sin
• Klassisk tilnærming
• Subdomene = Funksjon

22.
@mufridk
Gruppebehandling i sykehus

23.
@mufridk
Domenemodell

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

25.
@mufridk
Rollebasert
dekomponering
• Avgrensninger i systemet ut fra
hvilke roller som utfører ulike
funksjoner
• Tillater for mer oppgaveorientert
applikasjon
• Subdomene = Rollebasert funksjon

26.
@mufridk

27.
@mufridk
Domenemodell

28.
@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

29.
@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

30.
@mufridk

31.
@mufridk
Domenemodell

32.
@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

33.
@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

34.
@mufridk

35.
@mufridk
Domenemodell

36.
@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

37.
@mufridk
Flere eksempler på
forretningstjenester
Helsedomenet:
• Nevrokirurgi
• Føden
• Blodbanken

38.
@mufridk
Flere eksempler på
forretningstjenester
Forsikringsdomenet:
• Husforsikring
• Bilforsikring
• Personforsikring
Forretningstjenester istedenfor
funksjoner

39.
Om funksjonell
dekomponering
• Brukerbehovene blir gjemt bak
funksjoner!
• Svært lite bærekraftig modell !!

40.
@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

41.
Bok anbefaling #4

42.
Domain-Driven Design
Om prinsippene for strategisk DDD

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

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

45.
Språklige grenser
Ubiquitous Language
• Omforent språk
• Det samme språket overalt
• Samtaler
• Dokumentasjon
• Kode

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

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

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

49.
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»

50.
Takk for meg!
• https://www.linkedin.com/in/mufrid/

51.
@mufridk
Bilder
• https://unsplash.com/@x_vinicius
• https://unsplash.com/@mpho_mojapelo
• https://unsplash.com/@fazurrehman
• https://unsplash.com/@freegraphictoday
• https://unsplash.com/@dancristianp
• https://unsplash.com/@patrickperkins
• https://unsplash.com/@nadineshaabana
• https://unsplash.com/@chuttersnap
• https://unsplash.com/@ceebeesnap
• https://unsplash.com/@renemolenkamp
• https://unsplash.com/@rosiekerr
• https://unsplash.com/@janilson123
• https://unsplash.com/@profwicks