Domain Driven Design – för effektivare samarbete

När jag upptäckte domändriven design (DDD) var det lite som att hitta hem, och sedan dess använder jag tekniker därifrån dagligen. I DDD är målet att hitta en gemensam och formell beskrivning av en domän. Det handlar i första hand om hur vi tänker och om effektiv kommunikation. I andra hand om att använda objektorienterad utveckling på rätt sätt med hjälp av designmönster (design patterns).

DDD ger en produktiv kodbas

Kort går det att beskriva DDD som ett antal principer för mjukvaruutveckling:

  • Prata samma språk – ett ubiquitous language
  • Utforska och etablera en domänmodell tillsammans
  • Fokusera på ditt kärnområde – core domain

DDD beskriver även ett antal sammanlänkade design patterns som rätt använda leder till en ”supple design”. En produktiv kodbas som inte motarbetar dig utan hjälper dig när du vill införa förändring, en kodbas som gör dig glad!

Vadå design?

Design är ett ord som de flesta förknippar med form och färg. Webbdesign och industridesign handlar till exempel om att den färdiga produkten ska se bra ut för slutkonsumenten. I Domain Driven Design är den design du ägnar dig åt inte nödvändigtvis något som slutkonsumenten ser, utan design av en modell vars slutliga manifestation är kod. Kod är trots allt det viktigaste resultatet av ett mjukvaruprojekt. Domain Driven Design innebär alltså att vår domän driver vår design av kod. Men vägen till kod går via våra hjärnor. Vi måste förstå både problemet och lösningen för att kunna uttrycka den i kod.

Design patterns – designmönster

För den som inte upptäckt design patterns ännu finns en guldgruva av kunskap att upptäcka. Ett design pattern formulerar ett problem och en lösning till detta problem. Design patterns erbjuder alltså en katalog av beprövade lösningar. Dessutom ger de möjlighet till effektivare kommunikation genom att tillföra ett gemensamt språkbruk.

Vad är en domän?

En domän är ett kunskapsområde, en ”sfär av kunskap”. Exempel på en domän kan till exempel vara hus. I ett hus har vi rum av olika typ. Vardagsrum, toalett, tvättstuga, sovrum, hall, etc. De flesta tar för givet mängden information som finns i dessa ord.

Vi vet alla en hel del om till exempel vardagsrum: ofta är vardagsrummet det största rummet i ett hus, det behövs inte dras in vatten dit. El är viktigt, och tv-uttag likaså. Vi vill ha fönster och plats för en soffa och givetvis en TV.

I köket behövs både jordade uttag, vatten och avlopp. Vi har diskbänk, spis, kyl, frys, etc.

På toaletten behövs även där jordade uttag, vatten och avlopp.

husmodell

För elektriker, boende, VVS:are och fläktfolk så har dessa rumsord en betydelse som är universell och som gör att vi kan kommunicera effektivt. Vi tar det kanske som självklart men det är långt ifrån självklart inom mjukvaruprojekt, där det inte är ovanligt att varje ”skrå” har ett eget språk. Beställare kallar saker för en sak, domänexperter en annan, kravare, testare och utvecklare – alla kan de ha egna ord som beskriver liknande koncept. Inte sällan används ytterligare ord i koden som skrivs. De allra flesta programmeringsspråk har engelska nyckelord, och som en följd översätter oftast utvecklare sitt modersmål till engelska när de skriver kod.

Inom Domain Driven Design är det gemensamma språket så centralt att det finns ett eget begrepp för det – ubiquitous language.

Ubiquitous language – det allerstädes närvarande språket

Målet är att varje koncept i en domän har ett eget ord. Den produktivitetsvinst vi kan uppnå är så stor att det är värt att lägga ner åtskillig tid och möda för att komma fram till detta språk. För att hitta språket i en domän experimenterar vi fram en domänmodell. En ta fram en domänmodell är inget du gör på några dagar i början utav projektet, utan det är en iterativ process där utvecklare och domänexpert(er) tillsammans reder ut begrepp och deras samband. Den här processen måste pågå hela systemets livstid. Varje userstory beskrivs i termer av domänens ubiquitous language, och därigenom förfinas och utvecklas modellen. Den slutliga manifestationen av modellen är kod, och det är därför självklart att domänens ubiquitous language även används där.

Domänmodellen

Domänmodellen är en avgränsad precis beskrivning av en domän. Exempel på en modell kan vara ett sjökort, en förenkling av jordklotet med ett tydligt syfte – att navigera. Modellen kan till exempel utgöras av text, diagram, formler och bilder. Domänens ubiquitous language beskrivs i modellen och modellen beskrivs med hjälp av ubiquitous language. En domänmodell stöts och blöts  med återkommande diskussioner till exempel framför en whiteboard.

DDD Domain modeler and expert and whiteboard with hus

Core domain

Att ta fram en domänmodell tar tid, och det är inte självklart att alla delar i ett system är värda den omsorgen. Inom DDD finns det strategiska mönstret core domain som innebär att du tydligt avgränsar den viktiga kärnan, den del som gör systemet värt att skapa. Domäner som inte är core domain kan du till exempel använda standardsystem för – något som är otänkbart för core domain.

Var det allt?

Det jag hittills beskrivit är kärnan i DDD. Men det är bara början. När du öppnar ”the blue book” som Eric Evans Domain Driven Design kallas så möts du på insidan av pärmen av en översikt av de taktiska design patterns som tas upp i boken. Den avslutande pärmen visar de strategiska. De taktiska mönstren handlar om att utföra objektorienterad design och implementation på rätt sätt, medan de strategiska handlar om att hålla domänerna i ett system rena och fokuserade så att de blir till det vassa verktyg vi vill att de ska bli.

I våras släpptes Vaughn Vernons bok Implementing Domain Drive Design som givetvis kallas ”the red book”.

Utöver dessa böcker så finns ett levande community där du hittar ytterligare intressanta koncept och patterns som till exempel CQRS, Event Sourcing, och Domain Driven Security. http://dddcommunity.org/ är en bra utgångspunkt med gratis filmer, whitepapers, föredrag etc om DDD.

dddbook_implementing_DDD          dddbook_DDD

2 reaktion på “Domain Driven Design – för effektivare samarbete

Kommentera

E-postadressen publiceras inte. Obligatoriska fält är märkta *


fyra × = 24

Följande HTML-taggar och attribut är tillåtna: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>