Fokus på Domänen – Hur Decerno optimerar applikationsutveckling med DDD

Decerno omfamnar Domain-Driven Design (DDD) som kan ses som principer för mjukvaruutveckling, men också delvis som ett slags arkitektur. Begreppet låter sig inte definieras på ett kärnfullt sätt, men som namnet signalerar handlar det om att fokusera på domänen. Med domän menas det område inom en verksamhet – ett företag eller en organisation – som applikationen stödjer och modellerar. Domänen kan vara precis vad som helst, från ärendehandläggning på en myndighet till styrning av en industriprocess eller ekonomiadministration.

Designa med domänen i centrum

DDD har alltså domänen i centrum och fokuserar på vad som händer i denna domän, i verkliga livet och med domänen själv som utgångspunkt, i motsats till exempelvis tekniska detaljer. I stället för att bestämma sig för att använda till exempel en relationsdatabas (som SQL Server) och bygga en applikation givet möjligheterna och begränsningarna i databasen (tabeller, kolumner), börjar man med domänen och väljer (tekniska) lösningar efter behov.

Involvera alla kompetenser

En viktig princip i DDD är att alla inblandade, från domänexperter till programmerare, använder samma språk. Detta språk kallas ibland för Ubiquitous Language – det allomfattande språket – och är tänkt att täcka de begrepp som används i domänen. Samma ord används av alla, i muntlig och skriftlig kommunikation men också i själva koden (inklusive namn på variabler och tabeller/kolumner i en eventuell relationsdatabas). Det leder till att domänexperter och tekniker förstår varandra på ett sätt som inte alltid är självklart i utvecklingsprojekt.

Ett verkligt exempel på domain-driven design

Bättre än teori är ett exempel från verkligheten. Decerno har genomfört ett flertal projekt enligt DDD-principerna, bland annat utvecklingen av ett system för att räkna ekonomiskt på byggprojekt. Applikationen bygger på att all tillgänglig information om byggprojektet matas in i ett slags kalkyl som liknar en resultaträkning. Kalkylen kompletteras med så exakta uppskattningar som möjligt av projektets kostnader och intäkter, samt de tidpunkter vid vilka transaktionerna förväntas uppstå. All denna information vägs så småningom samman i ett nyckeltal/KPI som visar projektets ekonomiska duglighet. Systemet hanterar också så kallade investeringsärenden, som stödjer processen att fatta beslut om genomförande.

Ett av de första stegen som togs var att samla domänexperter, projektledare och utvecklare i designsessioner där vi tillsammans beskrev domänen på detaljnivå. I denna process skapades vårt Ubiquitous Language vilket fick uttryck i en ordlista med definitioner som visade sig mycket användbar under projektets gång. Eftersom det rörde sig både om ett flerspråkigt system och om en projektgrupp med olika nationaliteter, beslöt vi att använda engelska.

Nästa viktiga steg i DDD-praktiken blev att modellera domänen i form av Bounded Contexts och aggregat. Ett Bounded Context är det sammanhang inom vilket begreppen i Ubiquitous Language (och aggregaten) har en specifik och väldefinierad innebörd. Ett aggregat är en samling data och operationer som logiskt hör ihop i domänen. Dessa är nyckelbegrepp i DDD och en tidig lärdom är att indelningen i aggregat (och Bounded Contexts) är central, bör göras noggrant och så tidigt som möjligt. I vårt exempel från byggbranschen användes endast ett Bounded Context och aggregaten fick namn som Calculation, Account och Investment Case.

Värdeobjekt

Ett annat begrepp som används i samband med DDD är värdeobjekt. Värdeobjekt är mer tekniska och kan liksom DDD självt vara svåra att definiera. Det handlar om uppgifter som till sin natur är värden till skillnad från ”entiteter” eller identiteter. Ett svenskt personnummer är ett typiskt exempel, men också sådant som ett ordernummer eller ett kundnummer.

Värdeobjekt kan användas i implementationen för att tydligt skilja på värden som betyder olika saker, men tekniskt sett (och traditionellt) representeras likadant och därför kan sammanblandas av misstag. Man använder alltså en specifik värdeobjektstyp för ordernummer och en annan för kundnummer, i stället för enkla heltal. En annan fördel med värdeobjekt är att deras giltighet kan kontrolleras en gång och sedan garanteras. Det gäller personnummer men också till ett exempel ett antal som inte kan vara negativt.

Potentiella fallgropar med domain-driven design

Idel vinster med DDD alltså, finns det inga nackdelar? Det gör det förstås alltid, men Decernos erfarenhet är att de är få. En aspekt är att det kan leda till mer kod, eftersom man fokuserar på domänen och dess beteende och undviker tekniska genvägar. Ett annan möjlig fälla är att aggregatindelningen kan vara svår att få rätt från början och fel beslut får konsekvenser senare. Det bör kunna hanteras med en tillräckligt agil metodik.

Ett strålande resultat

Hur gick det då med systemet för byggprojekt? Det gick utmärkt, kunden fick sin applikation enligt plan, användarna är generellt mycket nöjda och kundens domänexperter förstår systemet på djupet. På köpet fick både kunden och utvecklingsteamet en djupare förståelse för verksamheten och en mental struktur uppburen av de formaliserade begreppen (Ubiquitous Language) som har varit till nytta för alla.

Vill du veta mer om DDD? Nätet är fullt av information, men en väg in är Eric Ewans klassiska bok Domain-Driven Design. Martin Fowler har också skrivit om ämnet på sin blogg.