DDD-kurs på Citerus

Jag har gått fyradagarskursen Domain-Driven Desing: Domänmodeller i arbete och tänkte försöka sammanfatta mina intryck.

 

Dag 1

Kursen var fullbokad med tio deltagare vilket tydligen var ovanligt bra då det t ex bara var jag och en till som ville gå kursen i september. En grupp kom från Umeå universitet, resten var spridda skurar från olika kunsultbolag från både Uppsala och Stockholm. Vi håller till på Lundqvist & Lindqvist vid Klarabergsviadukten 90. Det är fräscha lokaler med hembonad känsla och generöst med framställt fika på morgonen och på fikarasterna.

Det är Patrik Fredriksson från Citerus som håller kursen. Han har tidigare kört kursen tillsammans med "grundaren" av DDD, Eric Evans, och är väl insatt i ämnet. På morgonen får alla presentera sig och beskriva förväntningarna på kursen. Alla förväntas ha med sig en egen dator med en fungerande Eclipse-installation. Vi importerar de projekt vi ska jobba med under de fyra dagarna från en USB-sticka vilket går smidigt. Patrik går igenom grunderna och syftet med domändriven design, därefter paras vi ihop två och två och får börja titta på en klass som består av två metoder, den ena ca tjugo rader som på ett ställe anropar en lite mindre metod.

Övningen gick ut på att förstå vad klassen gör. Koden såg ut som riktigt dålig kod ibland kan göra vilket resulterar i att det tar ganska lång tid innan vi förstår vad koden är tänkt att göra. Därefter delas vi upp i två grupper, varvid jag hamnar i gruppen med sex personer. Uppgiften nu är att leta fram preconditions och postconditions och även att hitta bra begrepp som kan ingå i våran modell. Preconditions är de krav som behöver vara uppfyllda för att koden ska fungera, postconditions är i praktiken saker man kan testa mot om man skulle skriva ett enhetstest, d.v.s förväntat resutat. Med lite hjälp av Patrik lyckas vi sätta de flesta av kraven som behöver vara uppfyllda före och efter det att metoden anropas.

I nästa övning snyggar vi till API:et till vår metod något. Vi kör TDD och ändrar därför våra tester att fungera mot den nya metodsignaturen, varpå våra tester först blir röda, därefter implementerar vi varpå de blir gröna! Nästa övning går ut på att få oss att förstå att koden ser grisig ut på grund av att det saknas abstraktioner och begrepp för att beskriva vårat problem. Genom att införa nya begrepp så som som itinerary (resplan) kan vi till slut banta ned vår huvudmetod till hälften och på köpet öka dess läsbarhet. Genom detta sätt att jobba uppfyller vi ett par av de viktigaste tumreglerna inom programmering nämligen att hitta lagom stora byggstenar med ett tydligt ansvar (de nya klasserna i det här fallet) och dels att ha bra namn på saker! Det DDD trycker extra på är att de gemensamma begreppen ska användas både av verksamheten och även återspeglas i koden.

Dag 2

På förmiddagen fortsatte vi att jobba med våra testprojekt. Varje projekt speglar ett litet steg mot en bättre och förfinad modell där domänen är den samma som i Eric Evans bok, frakt av containrar. Varje steg följer samma mönster, praktik i form av kodning (TDD) som varvas med modellering i grupper med en fejkad domänexpert (Patrik). Det avslutas med en genomgång där Patrik presenterar "facit". Det är en bra blandning av diskussioner och praktiskt kodande. Övningsuppgifterna är väl definierade och syftar till att träna en viss del t ex huruvida testerna uttrycker mening och använder sig av ubiquitous language - det gemensamma språket. Precis som dag ett serveras det förutom lunch även rikligt med bakverk och dryck på rasterna och jag siktar på att gå upp ett halvt kilo!

Koncept så som domänevent (som tillkommit efter att Erics bok släpptes), aggregat och bounded context introduceras och diskuteras en hel del. Det trycktes en del på att aggregat används allt för sällan. Personligen tycker jag att aggregat är en bra konstruktion som omfamnar idén om inkapsling och hjälper till att reducera komplexitet när man bygger system. Därefter pratade vi om värdeobjekt som är en trevlig byggsten som dessutom är immutable! Vi anpassar vår kod att använda värdeobjekt, anpassar tester följt av genomgång med diskussioner. En rolig övning som genererade mycket diskussioner i vår grupp infann sig när systemet skulle stödja frågor om var containern befann sig. Det blev långa diskussioner där vi t ex hade tio förslag på vad en metod skulle heta; det är viktigt med namnsättning! Dagen avslutades med ett antal filmsnuttar som visade när en utvecklare försökte ta fram en domänmodell tillsammans med en domänexpert. Det gick väl si så där för honom men fick oss i alla fall att tänka till kring vad man bör tänka på i en sådan situation och att inte falla i samma gropar som han!

Dag 3

Denna dag ägnas åt genomgång av koncept på lite högre nivå så som strategisk design och annat. Det är rätt högt tempo där vi dels får göra en liten teaterövning där vi spelar olika roller för att simulera interaktionen mellan olika utvecklingsteam och externa parter som alla ingår i ett större system. Det blir en ganska kul övning som i slutändan går ut på att definiera de olika teamens relation till varandra. Ett exempel på en typ av relation är upstream-downstream där upstream inte tar hänsyn till downstream och där den senare kan drabbas av vad den förse hittar på.

Ett annat koncept som gicks igenom och övades på var distillation som går ut på att förstå och fokusera på de viktigaste delarna i systemet, det som i DDD kallas core. En av övningarna fick oss att förstå att core kan variera över tiden, där t ex en del kan gå från att vara core till att bli supporting d.v.s inte längre lika central. Ännu en bra dag fylld av diskussioner, om dag ett och två var innehöll mycket kodexempel så var de denna dag utbytta mot boxar och cirklar!

 

Dag 4

Dagen börjar med repetition av gårdagens övningar i kontextmappning och destilering av domänmodellen. Det följdes upp med en övning i att försöka bryta loss begrepp från våran RoutingService. När vi lyckats med det gick det lättare att resonera kring vad servicen gjorde då vårat domänspråk och implementation förfinats. Därefter tittar vi på koden i den DDD exempelapplikation som Citerus tagit fram. Den är visserligen nu två år gammal men fungerar bra som diskussionsunderlag. Någon noterade att applikationen använde sig av DTO:er vilket ses som ett anti-pattern. Jag tror vi kom fram till att man under vissa omständigheter borde kunna skicka rikare objekt än dumma databärare! DTO:erna hade hur som helst lagts till för att simulera kommuniikation med ett externt system.

På kursdeltagarnas begäran körde Patrik en liten genomgång av CQRS som också denna gång ledde till bra diskussioner. En kul grej var att en av deltagarna som kom från Ongame/Bwin hade praktiserat detta mönster i skarp drift för att lösa problematik kring många samtidiga användare.

En annan deltagare jobbade med ett system som bestod av en miljon kodrader och 800 databastabeller. Han tog upp problematik kring kodduplicering, där vi tillsammans spånade kring möjliga lösningar. De hade aggregat som behövde jobba mot samma tabeller men i olika kontext. Dessa aggregat var idag väldigt stora och mitt förslag var att ha ett aggregat skulle ha olika "skepnader" för respektive kontext, men att behålla den underliggande representationen genom att använda mönstret Context Switcher! Dagen avslutades med en halvtimme introduktion till Clojure ur ett DDD-perspektiv, vilket var en kul och intressant avslutning!

Om man som jag tycker att Eric Evans bok Domain Driven Design: Tackling Complexity in the Heart of Software är svårsmält föreslår jag följande preparering: läs Domain-Driven Design Quickly på strax över 100 sidorna som är en komprimerad version av boken och gratis, gå därefter denna fyradagarskurs och först därefter är du redo att ta dig an boken! Patrik Fredriksson föreslog fem genomläsningar och jag lutar åt att han menar allvar!

Sammantaget var detta en mycket bra kurs som jag rekommenderar till var och en som är nyfiken på DDD!