Varför är Domain-Driven Design mer relevant nu än någonsin tidigare?

Bakgrund - Mjukvaruprojekt framgång och misslyckanden

Enligt undersökningar gjorda av The Standish Group anses ca. hälften av alla mjukvaruprojekt som misslyckanden. Hur Standish Group definierat framgång vs misslyckaden och allt däremellan kan man googla sig till genom att söka “Standish Group Chaos Studies”. Med tanke på att de utfört dessa studier regelbundet sedan 90-talet så utgår vi i denna artikel från att dessa rapporter är högst tillförlitiliga och skall tas på allvar. Att notera är att vi för enkelhetens skull enbart pratar om agila projekt vilka är 2x mer sannolika att avslutas med framgång jämfört med traditionella (läs vattenfall) projekt. Även om dessa misslyckanden kan variera i grad och betydelse för slutprodukten så är det ett tecken att mjukvaruindustrin inte rört sig särskillt mycket åt rätt håll.

Lägg till de tekniska kliven som hänt i industrin senaste deceniet, möjligheter med molnet och floran av innovationer nya tekniker som borde göra det lättare att göra mer än nytta för verksamheterna ändå ser siffrorna ut som de gör. Att det finns en mängd anledningar till den här oförmågan att lyckas såsom byråkrati, oklara direktiv/specifikationer, otillräckliga resurser, storleken på projektet osv. är man överens om. (??) Men även när alla dessa är tillfredsställande så misslyckas vi så ofta. Vad kan vi göra bättre? Finns det något som vi redan känner till att vi gör fel i många projekt? Vad isf?

Mjukvaru entropi

När vi utvecklar ett nytt system är vi vanligtvis omptimistiska och har högt uppsatta mål med det vi vill åstadkomma. Vi vill skapa ett bra effektivt team där alla trivs och alla bidrar. Målet är som alltid att skriva så clean code som möjligt, skriva tester, följa best practices och beprövade mönster som finns etc. Den koden ska bli lika logisk och lätt att förstå om ett år som den är idag är vad vi säger oss själva. Sedan går det några år eller månader i vissa fall och vi (eller någon annan) behöver göra ändringar i det som vi skrivit relativt nyligen. Till vår stora förvåning märker vi att produkten (eller version 1 utav den) har redan divergerat från verksamhetens verklighet. Koden upplevs redan svår förståelig och svår att underhålla.

Faktum är att i de allra flesta fall även när första version av produkten är klar eller när projektet är klart så innebär inte det att koden är klart skriven. För lång tid framöver ska hänsyn tas till nya features/funktioner, buggfixar etc. Saker runt om förändras så även om vi inte har några nya funktioner att bygga är vi tvungna att ta hänsyn till föränderlig värld där infrastrukturen kontinuerligt måste uppdateras underhållas vilket har effekt på vår produkt vare sig vi vill det eller inte. Nyligen var jag med i ett projekt där en gammal .Net app behövde buggfixas. Även om fixen i sig var av enklare natur krävdes det en jätteinsats att få igång den med alla beroenden. Gamla versioner av Crystal Reports rapporter, gamla ORM mappers etc. Att den här appen var installerad och kördes på samma infrastruktur där annan verksamhetskritisk programvara fanns var inte till någon hjälp heller. När man hade fått igång den ena appen så slutade en annan fungera pga. de nya uppdateringarna. Problem efter problem dök upp pga. onödiga beroenden och naiv arkitektur.

Domain-Driven Design

Ämnet i sig är inget nytt och har stadigt växt i popularitet ändå sedan 2004 då det först introducerades av Eric Evans. Att påstå att det är mer relevant idag kontra tidigare är i minsta lag diskutabelt om inte helt fel. Det som inte är diskutabelt är att vi har så många fler möjligheter idag. Många av ingredienserna som gör Domain-Driven Design så komplett var svårare att ta till sig för 15 eller ens 10 år sedan. Inte många projekt genomfördes agilt år 2005 och inte så många visste vad en mikrotjänst var för något exempelvis. Ingen av dessa är egentligen ett krav i DDD receptet men de underlättar enormt eftersom några viktiga aspekter inom DDD sammanfaller väl med dessa.

De som räknar sina utvecklar kariärer i decenier och som har varit med om en o annan halvtlyckat projekt borde känna igen sig i väldigt mycket av det Eric skriver i sin bok. Utan att låta för XXXX? Jag vill påstå att många av dessa skulle räddas och/eller bli mer lyckosamma om de hade anamat Domain-Driven Design.

Det är inte helt trivialt att förklara omfattningen av DDD och dess praktiker, tekniker och principer. Genom att identifiera core domain, de unika grund värdena för en verksamhet guidas vi att prioritera rätt och göra rätt saker i rätt ordning. Det stannar inte där, vi uppmuntras definiera och förstå domänen lika väl som domänexperterna för hur ska vi annars skriva kod som motsvarar komplexiteten i domänen om vi inte förstår den? Det är också där organisationen skaffar sig övertag över dess konkurenter. Och ett möjligt försprång över våra konkurenter vill vi både behålla och utöka om så möjligt via bra mjukvara. DDD ämnar att ge oss vägledning när vi inte ska bytta utan köpa en färdig produkt. Om den mjukvara vi bygger inte ger oss några fördelar gentemot våra konkurenter då bör vi istället köpa en paketerad produkt.

DDD kräver seriösare och ett mer strukturerat tillvägagånssätt att tackla den komplexiteten som finns i verksamheterna. Det räcker inte att sätta ihop en grupp (eller flera) fullstack whatever, tekniker/uvecklare med någon typ av teknisk kunskap mata de med specar (eller ännu sämre inte ge de några alls) och förvänta sig att det de till slut levererar är det användarna, verksamheten fortfarande vill ha/behöver.

Anledning till att vi enbart pratar om agila projekt är delvis för att vi kan se att desssa projekt avslutas oftare med positivt resultat men också för att Domain-Driven Design i sig är orienterat mot de agila processerna där:

• Utveckligen är iterativ eftersom kraven utvecklas under projektets gång. Det är sällan kraven är fullständiga på förhand.
• Utvecklarna och verksamheten (sk. domän experterna) har nära relation till varandra.

Mönster (patterns) att förhålla sig till enligt DDD

• Model-Driven Design, mappa koncept, benämningar, arbetsflöden till kod. Sikta på en intim relation mellan modellen och implementeringen. Mappningen ska vara konsistent så att en ändring på modellen enkelt kan implementeras i koden och vice versa. Dessa ska alltid vara i sync och spegla varandra. Att analysera domänen blir på det här sättet synonymt med system design. För att koppla till agila methoder får vi möjlighet att göra snabba ändringar. Event-storming ett nytt spännande sätt för kollaborering mellan utvecklare och domänexperter för effektivare analys av domänen.
• Ubiquitous language - Samma språk, I en konversation mellan verksamhets personer och utvecklare ska båda sidor prata om beteende och egenskaper kring domänobjektet. Om de inte är är kapabla att kommunicera på det här sättet indikerar detta att det saknas något koncept i domän modellen.
• Bounded Context - problem områden beskrivs som domäner och subdomäner. Områden identifieras av kontext de hör till. Sker exempelvis genom att hitta gemensamt språk inuti varje kontext. 
• Entiteter, Value objekt och aggregat skapas ur modellen. regler för att underlätta implementation…