En fältstudie av hur domändriven design/DDD har använts i vidareutvecklingen av en del i en större applikation, med autentiska kodexempel. Avsikten är att konkretisera och inspirera.
Peter Backlund, presentation på Javaforum 2009-10-13
4. Vad vi hade
PeriodConfiguration getPeriodConfiguration(long personId,
long resourceGroupId,
long bookersAccessCategoryId,
long from,
long to)
• Utspridd logik
• Svag eller beteendelösa typer
• Svårt att studera, testa och förstå
4
5. Vägen till en kraftfull modell
• Domänexpert
• Strukturera kunskap
• Gemensamt språk
5
6. "Ok, vi säger att en lägenhet vill boka tvättstuga 3 den
22:a oktober mellan 14.00 och 18.00..."
65
8. "Man ska kunna ställa in så att om du
har bokat tvättstugan exempelvis tre
gånger den här månaden och alla
bokningar är aktiva så ska det inte gå
att boka en gång till förrän man har
tagit bort nån bokning eller man har
använt tvättiden, eller det blir en ny
månad.”
”Det är viktigt därför att vi har upptäckt
att folk bokar upp massor med pass
och då ... vilket leder till att ... och ...”
85
10. Struktur
En av flera bokningsregler lyder:
Ett bokningsobjekt ska kunna ställas in så att antalet
bokningar per bokare per månad är begränsat till X st.
En bokningsförfrågan tillåts om bokaren har färre än X
aktiva bokningar av det bokningsobjektet under den
månad då passet infaller, eller om ingen begränsning är
satt.
10
Hej jag heter ... och jag ska prata om poängen med domändriven design och berätta om hur vi använder det i mitt nuvarande uppdrag.
Hej jag heter ... och jag ska prata om poängen med domändriven design och berätta om hur vi använder det i mitt nuvarande uppdrag.
Med ordet ”domän” i domändriven design menas verksamhetsområde, det företaget eller myndigheten ägnar sig åt.
Jag jobbar med ett stort och etablerat elektroniskt passersystem som styr vem som får komma in när och var. Det här systemet består av massor av moduler, varav en hanterar bokning, alltså tvättstugor, konferensrum, tennisbanor osv. Den här modulen stod i tur att genomgå en rad förädringar, av olika anledningar.
Koden som fanns var svår att jobba med. Affärslogiken var utspridd över alla lager, ibland i nån if-sats i en jsp-sida, ibland i en SQL-sats och allting däremellan. Mycket var duplicerat.
Primitiva typer användes väldigt ofta, som ni kan se i den här autentiska metodsignaturen. De ”domän”klasser som fanns hade i princip inget beteende eller inre validering, utan var rena databehållare. Det var transaktionsskript och blodfattig modell fullt ut.
Det här var svårt att sätta sig in i och svårt att testa på ett meningsfullt sätt.
Vi ville förändra det här. Vi ville bygga en kraftfull modell som kunde lösa domänens problem, alltså svara på vem som får boka vad och när, på ett robust och kärnfullt sätt.
En av de viktigaste ingredienserna för att lyckas med DDD är att man har tillgång till en domänexpert. DE är en person som vet hur verksamheten fungerar och varför. Det kan handla om ren sakkunskap, produktens och affärsverksamhetens historiska utveckling och framtid, hur användare interagerar med produkten i vanliga situationer och liknande. En person som har lång erfarenhet av domänen. I vårt fall fungerade vår produktägare som domänexpert, vilket inte alls är nödvändigt med oftast är bra. Det kan möjligen leda till att PO tror sig kunna detaljstyra arbetet mer än vad som är nytttigt.
Vi bjöd in DE till modelleringssessioner. Uppskattat.
När man ska modellera tillsammans med DE är det viktigt att ta vara på tiden. Vara förberedd men inte förutfattad. Läs på, skissa på idéer, men var beredd att lyssna och ompröva, och var noga med att inte köra över DE. Arbetet handlar om att överföra kunskap från DE till utvecklarna, och att strukturera den här kunskapen på ett sånt sätt att vi kan skriva kod som fungerar på samma sätt.
För att kunna överföra och strukturera kunskap på ett effektivt sätt måste vi använda ett gemensamt språk, ett språk som vi vill ska återkomma i diskussioner mellan DE och utvecklare, utvecklare emellan och till och med inne i källkoden. Språket bildas normalt som ett urval av etablerade termer och fackspråk, men ibland kan man behöva införa nya begrepp, sätta namn på koncept som man pratar om under modelleringen.
Den här typen av meningar var ofta avstamp när vi testade olika scenarier. Allt som ingår när ett initiativ att boka något sker: vem, vad, när. Vi valde att införa begreppet Bokningsförfrågan.
När vi införde begreppet innebar det också att vi skapade en klass med samma namn, med fält som svarar mot begreppets innebörd.
ValueObject är ett av flera designmönster som hjälper oss att karaktärisera våra klasser. Andra exempel är entity, repository, factory och service.
Ja, ni ser rätt. Koden är på svenska. Jag antar att majoriteten av er rynkar på näsan åt det, det hade jag själv gjort för ett år sedan. Jag har dock helt ändrat uppfattning i den frågan och ser det numera som ett privilegium att kunnna skriva kod på svenska. Det är en naturlig konsekvens av att försöka anamma ett gemensamt språk.
--- PAUS ---
Nu tänkte jag att vi skulle titta på språk, modell och kod hänger ihop i ett lite mer matnyttigt exempel. Under en modelleringssession tillsammans med DE skulle man kunna tänka sig att det låter såhär (LÄS).
Vår uppgift är nu att strukturera den här kunskapen för att kunna åstadkomma mjukvara i andra ändan. Vi skissar på whiteboard eller papper, försöker hitta mönster, preciserar, generalisera, ställer motfrågor, provar scenarier, gör saker explicita.
När vi kommit en bit på vägen så kan det se ut såhär, efter att ha experimenterat och modellerat, strukturerat kunskapen, kunna beskriva samma sak med väl etablerade termer (LÄS).
Fortfarande ”normal” svenska, fullt förståeligt för en domänexpert. Det här är kontaktytan mellan domänen och koden.