For en stund siden fikk jeg spørsmål fra en kollega i CoWork om å beskrive hensikten med Domain-Driven Design (DDD). Jeg tenkte med en gang at det var en frisk tilnærming til temaet og en fin utfordring. Jeg har ofte opplevd at ved introduksjon av en ny metodikk, verktøy eller arbeidsprosess, går spørsmålene mer i retning av «Hva er det?» istedenfor «Hvorfor skal vi bruke det?».
Mange år med konkret taktisk og operasjonell erfaring i produktutvikling av komplekse IT-systemer har vist meg at mål og hensikt oppdages gjerne gjennom samarbeid og i felleskap. Samarbeid handler ofte om læring. Læring om komplekse domener der tverrfaglige team opererer og flytter seg sømløst, og gjerne ubevisst, mellom problem-og løsningsrommet. Jeg opplever at det er i skjæringspunktet mellom disse begrepene at vi finner hensikten med Domain-Driven Design!
Det finnes både akademiske og empiriske tilnærminger til definisjon av kompleksitet, men det er fullt mulig å ta dette ut fra et subjektivt perspektiv. Kjenn litt selv på tyngden av faglige problemstillinger, menneskelige forhold og en lang rekke av ad-hoc løsninger i dine omgivelser. Om dette helhetsbildet kommer med høy kognitiv last, da kan vi snakke om kompleksitet! For å adressere dette, lærer vi fra DDD om å skille mellom naturlig (eng. inherent) og utilsiktet (eng. accidental) kompleksitet. Den naturlige kompleksiteten eksisterer i forretningsdomenet og denne må vi omfavne og bygge våre løsninger rundt. Den utilsiktede kompleksiteten tilfører vi selv på teknologi- og organisasjonsplan, og det mange i DDD-fellesskapet vil påpeke er at de to områdene er uatskillelige! For å unngå utilsiktet kompleksitet trenger vi å se på måten vi er organisert på og velge verktøy for å fremme felles forståelse av behov mellom brukere, forretningssiden og teknologer, mao. bygge tverrfaglige team!
Jeg betrakter et produktteam som tverrfaglig hvis teamet har evne til å forstå forretningsdomenet der teamet skal levere sine produkter. Den faglige bakgrunnen i både forretnings- og teknologi-sfæren hos ulike teammedlemmer er essensielt dog utilstrekkelig. Det vi ofte trenger i tillegg er et tankesett som lar teamet koble sammen domeneforståelsen med mulighetene som teknologien byr på. Denne tilnærmingen til tverrfaglighet er noe av de mer konkrete bidragene som DDD har brakt til IT-bransjen, nemlig bevisstgjøringen av at de beste løsningene oppstår i tett og mest mulig direkte samarbeid mellom programvareutviklere og domeneeksperter. Dette samarbeidet fasiliteres av et sett med engasjerende visuelle verktøy og metodikker, der problemområdet analyseres og helhetsoversikten oppnås på rimelig kort tid.
IT-industrien har kanskje noe unaturlig definert dette skillet (mellom programvareutviklere og domeneeksperter) i form av kravspesifikasjoner, produkt backlogg etc. på den ene siden og kjørende kode på den andre siden. I bunn og grunn handler det om tilbakemelding fra forretnings-og brukerbehov tilbake til utvikling av programvaren som oppfyller behovene.
Som et effektivt kommunikasjonsmiddel legger DDD særlig vekt på modellering som en ferdighet som må læres og øves i. Med modellering analyserer vi problemrommet ved å lete etter konsistens i språkbruken hos våre brukere i avgrensede deler av forretningsdomenet. Dette konsistente og avgrensede språket kaller vi i DDD for omforent språk (eng.Ubiquitous Language). Derimot aksepterer vi at på tvers av problemrommet er er språket tvetydig og inkonsistent! Vi utnytter dette ved å velge å dele opp våre systemer slik at vi tillater ulik betydning av domenebegreper i ulike avgrensede deler av systemet. Et populært eksempel er begrepet tomat som noen anser som en grønnsak og noen som frukt; noe som er helt ok dersom de ikke sitter i samme møte og diskuterer tomater!
Der vi oppdager omforent språk definerer vi en avgrenset kontekst (eng. Bounded Context) i systemet. Med modellering av løsningsrommet vil vi da oppnå et IT-produkt der resulterende programvare reflekterer den mentale modellen til en domeneekspert. På den måten tilpasses produktet mest mulig forretningsbehovene som ligger til grunn. En av forutsetningene for å få til dette er kontinuerlig forbedring av modellen ettersom teamet erverver ny lærdom og får nye tilbakemeldinger underveis. Ved at teamet og domeneeksperter samarbeider om å lage gode modeller skaper man eteffektivt verktøy for å korte ned på tiden det tar å få tilbakemelding tilbake til produktteamet.
Denne iveren etter å finne et felles, omforent språk innen en avgrenset kontekst har i tillegg et annet bruksområde. Det omforente språket kan da brukes i kommunikasjon internt og eksternt, i tverrfaglige team, av utviklere,designere, testere, ledere og spesielt mot sluttbrukere og sluttbrukernes representanter. Utviklingen av dette språket bringer med seg ny kunnskap og lærdom om sammenhengene og avgrensningene i problemområdet.
Det finnes både utfordringer og en viss kostnad for produktorganisasjonen å ta i bruk DDD. Det som kan brukes som veiledning for om det er hensiktsmessig i å investere i DDD er et sett med relativt enkle spørsmål.
· Er forretningsdomenet tilstrekkelig komplekst?
· Finnes det tilgang til domeneeksperter?
· Har produktteamene vilje til å lære mer om modellering og å bruke det eller andre kanaler for å få rask og god tilbakemelding på modellen som implementeres i kildekoden?
En klassisk utfordring og en gjenganger for de fleste organisasjonene er tilgang til domeneeksperter. Om vi er heldige er en domeneekspert allerede del av produktteamet, eller i det minste jobber i organisasjonen teamet er en del av. Utfordringen øker fort jo lenger domeneeksperter befinner seg utenfor teamet/organisasjonen og tilgjengeligheten til kunnskapen deres følgelig blir mer begrenset.
En annen utfordring er tilpasning av IT-produktet til behovene til både sluttbrukere og forretningsinteressenter. De kan være sammenfallende, men samtidig avvikende på flere områder. Her er det viktig å ta lærdom fra andre fagdisipliner som f.eks Design Thinking slik at organisasjonen har flere verktøy til rådighet. Slik blir organisasjonen mer fleksibel ut fra kundens behov. I CoWork ser vi eksempelvis at DDD og Design-Thinking komplementerer hverandre bra i innsiktsfaser i produktutvikling.
Domain-Driven Design utfordrer oss til å bli mer tverrfaglig, til å søke kunnskap hos andre fagdisipliner og å være nysgjerrige på alternative løsningsperspektiver. Vi oppfordres til å stadig forbedre vår forståelse av omgivelsene der IT-produktet vi leverer skal være en del av. Det handler om å adressere behovene til mennesker som er sluttbrukere eller har på andre måter interesser i IT-produktet som bygges!
Da prøver jeg til slutt med en definisjon av hensikten med Domain-Driven Design:
DDD hjelper deg å unngå å lage unødvendig komplekse IT-løsninger, ved å respektere behovene til mennesker som jobber i forretningsdomenet via tett tverrfaglig samarbeid.
Om du er nysgjerrig på hvordan du kan oppnå dette, hjelper vi i CoWork med både kursing og coaching i Domain-Driven Design slik at du kan anvende våre gode råd til dine problemstillinger i dine omgivelser. Ta gjerne en titt på vårt kurstilbud innen DDD!
