Hva gjør vi når kunden kommer til oss og fronter et problem? Setter vi oss ned og begynner å skrive kode, eller prater vi med kunden for å forstå domenet og problemstillingen?
La oss bare innrømme det først som sist: Vi er ikke domeneeksperter. Vi er innleide teknologer som skal løse komplekse problemer sammen med kunden. Det spiller ingen rolle om du er en racer på node.js, react, dotnet eller lignende, om vi ikke løser de utfordringene kunden har.
Denne bloggposten er ikke ment som en oppskrift eller regelsett på hvordan vi angriper problemstillinger kunden gir oss, men mer som tips og råd jeg har etter åtte år som utvikler og tech lead i konsulentbransjen.
Teknikker som har hjulpet meg:
- Event storming workshop
- Domenedrevet Design (DDD)
- Involver domeneekspertene under utviklingsprosessen
Kode som overlegent designverktøy
"Kode er egentlig det eneste verktøyet vi kan lage grensesnitt med" skriver Halvor i Bring.
Event storming
Start med en event storming-workshop i samråd med domeneeksperter og interessenter. En slik workshop hjelper deg å identifisere avhengigheter innenfor domenet, og hvordan de ulike komponentene i systemet reagerer på hverandre. Altså hvordan komponent X reagerer på en endring i komponent Y.
Event storming handler om å identifisere handlinger og reaksjoner, og er en meget enkel affære.
Man samler alle interessenter i et rom med ubegrenset modelleringsflate. Gjerne i form av et stort ark teipet på veggen. Bruk post-it lapper som beskriver flyten i forretningsprosessene. På denne måten blir det lettere å identifisere avhengighetene i applikasjonen, diskutere seg frem til alternative løsninger og belyse ubesvarte spørsmål før man begynner med implementasjonen.
Event storming er selvsagt mye mer komplekst enn det vi får plass til på tre avsnitt. Men dette er en kort forklaring på verktøyet du kan bruke. Ønsker du mer informasjon, så har jeg linket til gode kilder helt til slutt.
Domenedrevet Design
Domenedrevet design (DDD) har hjulpet meg en hel del når det kommer til modellering av applikasjonen. DDD hjelper deg med å oversette forretningsprosesser til kode. I tillegg holder det kodeverket som beskriver disse prosessene innenfor sin kontekst i objektstrukturen du jobber i.
Klassene beskriver dermed seg selv, og dokumentasjon av kode blir unødvendig siden du skriver selvforklarende kode. Så selvforklarende at du kan sitte sammen med en ikke-teknisk person og programmere.
«Dokumentasjon av kode blir unødvendig siden du skriver selvforklarende kode»
Jeg har sett mange kodebaser som ikke har benyttet seg av DDD, fordi det tidvis kan være vanskelig å identifisere de ulike aspektene ved domenet. Et uttrykk som kommer til overflaten i DDD, er “bounded context”. Dette er en logisk gruppering av subdomener innenfor det definerte kjernedomenet det jobbes innenfor.
Motsetningen til DDD, er en modell som kalles “anemic datamodel”, eller en anemisk datamodell. Martin Fowler og Eric Evans definerer en anemisk datamodell som et anti-pattern. Her modelleres ikke forretningsregler og oppførsel inn i domeneklassene, men blir heller spredd utover andre abstraksjonslag, som for eksempel service- og helper-klasser.
Virker dette kjent? Problemet med en slik tilnærming er at vi lar utenforstående komponenter endre tilstanden og oppførselen til domenet vårt. Det er jo domenet som må forstå hva som skal til for at dens egen oppførsel og tilstand skal endres.
«Any fool can write code that a computer can understand. Good programmers write code that humans can understand.» Martin Fowler
Et annet begrep som kommer med domenedrevet design er Ubiquitous Language. Ubiquitous Language er et felles språk som forretningen og utvikleren prater. Ved å introdusere dette slipper man at utviklere prater et språk som må oversettes til forretningen. Vi må ikke blande engelsk og norsk, eller flere begreper innenfor samme språk.
La oss ta et eksempel:
Du sitter hos en kunde som utvikler pasientjournaler. Forretningssiden omtaler eierne av en journal som pasienter, men i kodebasen er dette navngitt som «brukere». Ser du forvirringen som kan oppstå?
- Hørt flere historier om skyhøye regninger fordi man glemte å skru av ting
Christian Johansens beste tips mot skyhøye skyregninger.
Hva om denne pasienten skal endre bostedsadresse hvor forretningssiden omtaler dette som en adresseendring, men koden som skal utføre oppgaven heter «ChangeAddress». Hvilken adresse snakker vi om? E-post? Leveringsadresse for medikamenter?
Vi gjør det enklere for oss selv om vi tilpasser oss språket som brukes. Så hvis forretningen omtaler sine prosesser på norsk, skal koden også skrives på norsk.
Involver domeneekspertene
Greit, vi har nå vært en kjapp tur innom event storming og domenedrevet design. Vi har definert forretningsprosessene, avhengighetene i løsningen, og koden vår reflekterer måten forretningen prater på. Hva nå? Er vi ferdig? Svaret er nei.
«Tenk deg om to, gjerne tre ganger, før du programmerer.»
Min oppfordring er å involvere domeneekspertene kontinuerlig under utviklingsprosessen. Ikke sitt alene i en sprint og programmer. Det går som regel galt, da vi alltid vil støte på ubesvarte spørsmål som ikke dukket opp under de tidligere stegene i modelleringen av applikasjonen.
Min bønn til deg, kjære konsulent, er å tenke deg om to, gjerne tre ganger, før du programmerer. Involvér interessenter kontinuerlig og bruk det samme språket som forretning, så slipper du en hel del forvirringer. Det er slik gode løsninger skapes.
Anbefalt lesing:
- Hands-On Domain-Driven Design with .NET Core: Tackling complexity in the heart of software by putting DDD principles into practice — Zimarev, Alexey
- Domain-Driven Design: Tackling Complexity in the Heart of Software — Eric Evens
- Exploring CQRS and Event Sourcing: A journey into high scalability, availability, and maintainability with Windows Azure (Microsoft patterns & practices) — Betts, Dominic
- https://www.lucidchart.com/blog/ddd-event-storming