En arbetsskada jag fick med mig från min tid som doktorand är förtjusningen över enkla och tydliga konceptuella modeller. Jag vill minnas att min far en gång sa att det går att bli intresserad av nästan vad som helst, bara man lägger ner tillräckligt med energi på det. Efter sju år på universitetet är det svårt att säga om det där med konceptuella modeller någonsin var ett genuint intresse hos mig eller om jag formade mig själv till att tycka om dem. Men det finns någonting vackert i att ta något komplext, abstrahera det och fånga essensen i en modell. Dessutom kan jag efter min tid i den akademiska världen konstatera att det är jävligt svårt.

Anledningen till att jag pratar om det här är att jag sprang på en sådan modell tidigare idag när jag bläddrade igenom Evans fantastiska bok Domain-Driven Design – Tackling Complexity in the Heart of Software. Modellen i sig är inte på något sätt central i boken men den är sjukt tydlig och enkel vilket gör att den kvalar in på min ”modeller jag gillar”-lista. Dessutom var den så enkel att rita av att jag slipper åka dit för stöld. 😛 Här har vi den:

Jag ska beskriva begreppen så att det hela blir lite mer begripligt för er som inte har koll på Domain Driven Design (DDD). Modellen (”Model” i figuren ovan) är ett centralt begrepp i DDD och utgör en abstraktion över utvalda delar av en domän som kan användas för att lösa verksamhetsproblem. Modellen i sig är något abstrakt – var och en av oss bär på olika mentala modeller över hur saker och ting förhåller sig till varandra – och den kan konkretiseras på lite olika sätt. Ett sätt är att rita ett diagram. Ett annat sätt (som förespråkas i DDD) är att implementera modellen i programkod. Implementationens utformning blir då systemets design (”Design” i figuren ovan). Det man med DDD vill uppnå är att minimera avståndet mellan Model och Design till den grad att det inte finns någon egentlig skillnad. Måhända utopiskt men mycket fräckt.

Allt eftersom man får en ökad förståelse av modellen gäller det att överföra det man lärt sig till designen. Detta är alltså en iterativ process (som pilarna påvisar). Centralt i figuren har vi även ”Paradigm” som en länk mellan Model och Design. Här menar Evans att valet av programmeringsparadigm är en viktig faktor för att man ska kunna uttrycka modellen på bästa sätt. Det kan vara så att objektorientering inte är det bästa valet bara för att det är något man är van vid.

Anyhow, jag tror jag har fått fram min poäng. Enkla och tydliga figurer får mig att mysa! 🙂