DDD i befintliga system


När jag var på den där workshoppen i yoga för män för ett par veckor sedan sprang jag på en gammal kollega. Vi kom efter en stund att prata om Eric Evans idéer om Domain-Driven Design (DDD). Både min kollega och jag tycker att DDD är väldigt spännande och funderingen vi vände och vred på var om och i så fall hur man ska kunna applicera i alla fall delar av DDD i befintliga projekt. Vi klurade en kort stund innan det var dags att åka hemåt för att återgå till familjelivet igen. Vad jag inte kom ihåg under vårt samtal var att just Eric Evans hade pratat om detta i en fin liten videosnutt.

Om jag inte minns fel utgick han ifrån en arkitekturell verklighet som säkert är väldigt bekant för många av oss: Big ball of mud. Hans poäng i videon (spoiler alert) är att introducera ett slags ”växthus” för de funktioner man avser lägga till eller förändra. All kommunikation mellan växthuset och resten av systemet sker genom något som i DDD kallas för Anti Corruption Layers (ACL), vilket är ett fint begrepp för datamappning som syftar till att bibehålla den interna modellen i växthuset isolerad från resten av systemet. Ett sådant upplägg gör att man i växthuset kan modellera och bygga upp någonting vackert och kanske lite sagolikt – vad vet jag.

För en systemutvecklare som har harvat runt bland svårbegriplig kod år efter år låter detta smått fantastiskt – tänk att få skapa en perfekt verklighet i en liten fin bubbla. Jag blev själv hänförd när jag såg presentationen och jag tycker fortfarande att idén är intressant, men jag tror att jag tänker på den nyktrare nu. Att bygga ett växthus mitt i en kodbas innebär ett avbräck från den befintliga arkitekturen. Jag menar att även en big ball of mud har en arkitektur, en tanke eller en ”såhär brukar vi göra” som man som utvecklare snällt har fått lära sig. Ett växthus innebär att man skapar en liten arkitektur i arkitekturen så att säga. Alla involverade måste lära sig den nya arkitekturen och förstå den för att inte kvadda den under det pågående förändringsarbete av kod som är systemutveckling. Det kräver engagemang och disciplin hos alla för att fungera.

Dessutom kan man aningen motsägelsefullt se det som att man gör koden mer svår att förstå om man ser på hela systemets kodbas sammantaget. Växthuset bryter jargongen som finns, det blir lite som att en författare helt byter sitt språkbruk för ett kapitel i en bok. Hur vacker prosan än må vara i just det kapitlet sticker det ut som förvirrande i det att det skiljer sig från resterande innehåll. Om vi sedan tänker oss att vi slänger in ett par sådana växthus med viss skillnad i arkitektur finns det risk att vi har skapat oss ett förvaltningshelvete.

Utan att vara framme vid någon slutsats tänker jag att Evans idé är väldigt djärv och att det gäller att vara sjukt säker på sin sak innan man ger sig på en sådan grej. Koden måste kommunicera bra och det gör den bäst när den är konsekvent, vacker eller ej.


Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *