Domain Driven Development

Domain Driven Development (DDD) var min sidste tutorial til dette års JAOO. Det var Eric Evans fra Domain Language Inc., der stod for dagens program. Jeg havde ikke tidligere hørt om DDD, så jeg glædede mig til at se, hvad dagen ville bringe. Jeg havde set Eric Evans til det afsluttende diskussionspanel i onsdags og jeg må indrømme, at han ikke lige virkede som en person, der ville kunne holde mig vågen i 7 timer på en fredag efter en hård uge.

Heldigvis viste det sig hurtigt, at der ikke var nogen grund til bekymring. Godt nok var Eric hverken humoristisk eller havde nogen imponerende måde at fremlægge sit budskab på - men emnet var super spændende. For at få os alle til at tænke i de samme baner, blev det meste af formiddagen brugt på et eksempel på DDD. I eksemplet skulle der udvikles et system til fragt af containere. Første spørgsmål var derfor, hvilke elementer vi ville have med i vores design. Hvordan skal en rute f.eks. repræsenteres i et sådant system - skal de enkelte stop på ruten gemmes eller skal det være "benene" mellem stoppene der gemmes? Der blev via diskussioner vægtet for og imod hver af kandidaterne og det endte med, at vi tog benene med i vores model. Det viste sig senere, at det ville have været smartere, hvis vi havde valgt stoppene, da der var mere databehandling omkring disse. Spørgsmålet var så nu, om vi skulle tage stoppene med og beholde benene, eller hvordan vi skulle komme videre. Det endte med, at vi beholdt benene, da det ikke krævede meget ekstra arbejde, at "regne" fra ben til stop. Vi fik nogle spændende diskussioner, hvor det var helt tydeligt, at folk løser designopgaver på vidt forskellig vis.

Vi havde nu selv prøvet at tænke over, hvilke elementer fra domænet, der skulle med i vores design. Næste skridt var, at vi skulle se en række videoer, hvor en udvikler snakkede med en domæneekspert. Alle videoer var 10-60 sekunder lange og efter hver video tog vi en diskussion om det, der blev snakket om i videoen. I en video skete der det, at udvikleren brugte nogle ord, som domæneeksperten ikke kendte - i en anden video skete det omvendte. Som udvikler er det vigtigt hele tiden at koncentrere sig om, ikke at bruge ord som domæneeksperten ikke kender, da dette kan lede til forvirring og måske endda betyde, at domæneeksperten ved en fejl godkender noget, som ikke giver mening i domænet.

Alt i alt en spændende dag - som slet ikke var så kedelig som forventet :-)

Kommentarer (1)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Torben Mogensen Blogger

Meget frustration over IT systemer skyldes formentlig, at udviklerne ikke i tilstrækkelig grad har sat sig ind i domæneeksperternes metoder og terminologi, så brugerne med IT systemet bliver præsenteret for ikke-standard terminologi og tvinges til at bruge andre metoder, der ikke nødvendigvis er bedre end de traditionelle.

Så det er absolut relevant at sørge for at udviklerne har en god forståelse af domænet og allerhelst, at domæneeksperterne inddrages i designet.

Det betyder ikke nødvendigvis, at man skal gøre alt, hvad domæneeksperterne siger. Deres metoder kan være påvirket af mangel på IT-støtte, så de slet ikke tænker på, hvordan ting kan gøres nemmere med IT. Men eventuelle geniale ideer fra udviklernes side bør i så fald diskuteres med domæneeksperterne.

Jeg er selv glad for ideen om domænespecifikke sprog -- dels giver de udviklere og domæneeksperter bedre mulighed for at snakke sammen (domæneeksperterne kan forstå, hvad der foregår i programmerne, og udviklerne kan nemmere omsætte eksperternes metoder til programmer), og dels kan eksperterne i et vist omfang selv løse mindre programmeringsopgaver.

  • 0
  • 0
Log ind eller Opret konto for at kommentere