Informationsarkitektens bokhylla – del 4: Om informationsmodelleringens strategi
När vi informationsmodellerar behöver vi ofta hantera domäner som sträcker sig över flera kontexter. Då ställs vi inför svåra avvägningar. Boken Domain-Driven Design, skriven av Eric Evans, lär oss strategier för detta. Ingen annanstans finns det så många kloka saker sagda om vad vi egentligen håller på med som informationsmodellerare, allt från teori till praktiska tips. Trots att Evans egentligen inte alls riktar sig till informationsmodellerare.
Eric Evans lyfte fram domänmodellens betydelse
År 2004 kom en bok med titeln Domain-Driven Design. Den blev starten till en rörelse bland systemutvecklare. Boken satte fokus på något som egentligen alltid varit den bärande principen inom den objektorienterade paradigmen, nämligen hur man ska designa programkoden så att den så bra som möjligt uttrycker vår mentala modell av problemdomänen. Det är en förmåga som skickliga utvecklare tidigare hade tillägnat sig som en tyst kunskap, något som de behärskade men inte riktigt hade kunnat förmedla verbalt. Författaren Eric Evans var den första och hittills den enda som lyckats förmedla med ord hur man kan tänka och hur man kan bli bättre på denna konst.
Boken handlar som sagt om den gemensamma modell vi har i våra huvuden om det som verksamheten hanterar, det vill säga vår domänmodell. Den har sin mest konkreta implementation i programkoden. Och den bärande idén i Domain-Driven Design är att det är domänmodellen som ska driva designen av programkoden. Programkoden ska verkligen uttrycka den gemensamma modell vi har i huvudet.
Hur blir en bok om programmering intressant för informationsarkitekter?
Författaren Eric Evans är en mycket erfaren programmerare och boken är en syntes av hans erfarenheter. Jag har träffat honom några gånger. Han är en tankfull och ödmjuk person som när han får en fråga tänker länge för att sedan komma med ett mycket genomtänkt svar.
Varför är då en bok om programmering intressant för en informationsarkitekt? Trots att inget i boken sägs direkt om informationsmodeller, utan där allt handlar om programkod?
Jo, vår informationsmodell är ju den mest synliga och gemensamma manifestation av domänmodellen, det vill säga den mentala modellen av allt det som hanteras i det sammanhang vi verkar. Den kan omfatta kunder, ordrar, avtal, produkter, leveranser, konton med mera. Och den bör givetvis utvecklas i samklang med de it-system vi utvecklar, databaser, programkod, användargränssnitt, rapporter, tjänster med mera. Allt som har samma kontext bör i möjligaste mån ha en gemensam konceptuell modell.
Nästan allt som står i boken är intressant för en informationsmodellerare. Ingen annanstans finns det så mycket kloka saker sagda om vad vi egentligen håller på med, allt från teori till praktiska tips.
Jag har för vana att göra förstrykningar i marginalen på böcker jag läser. Ett streck när jag läser något som fångar mig, dubbla streck när det blir riktigt intressant och tre streck när det verkligen är något som jag vill ta med mig för framtiden. Jag har ingen annan bok med så många tredubbla streck i marginalerna.
Boken är på 530 sidor. Ibland har jag sagt till kollegor: ”Man kan slå upp boken på måfå, så står det något intressant.” De som har testat brukar instämma.
Tråkigt nog når boken sällan informationsmodellerare. Nästan ingen utanför programmerarnas led läser den. Uppfattningen är nog att det är en bok endast för programmerare. Förståeligt men tråkigt.
Bokens innehåll
Bokens har fyra delar, var och en med sin egen inriktning:
Part I: Putting the Domain Model to Work (62 sidor)
Den första delen av boken handlar om hur modellen och designen av programvaran formar varandra, ömsesidigt. Om vi gör rätt blir modellen det språk alla inblandade använder och som utrycker vår gemensamma förståelse i destillerad form. Det har avgörande betydelse hur vi formar detta gemensamma språk och hur vi gör så det verkligen blir gemensamt för alla inblandade.
Part II: The Building Blocks of a Model-Driven Design (123 sidor)
Den andra delen av boken handlar mer specifikt om design av objektorienterad programkod, och är kanske den minst intressanta delen för en som inte programmerar.
Part III: Refactoring Toward Deeper Insight (139 sidor)
Tredje delen handlar om vikten av att jobba iterativt med modellen.
Begreppet ”refactoring” brukar ömsom översättas till ”refaktorering” eller ”refaktorisering” på svenska, och är ett begrepp som skapades av programmerare i början på 90-talet.
Refaktorering av programkod innebär rent konkret att man ändrar existerande programkod utan att påverka dess externa beteende. På så sätt kan man, i många små kontrollerade steg, bit för bit utveckla en programvaras design, struktur och implementation. Man vill minska komplexiteten och öka läsbarheten för att programvaran ska bli lättare att underhålla. Målet är en enklare, renare och mer uttrycksfull programkod.
Men refaktorering är samtidigt så mycket mer. Att regelbundet refaktorerera som en del av all programmering innebär ett arbetssätt och en filosofi om hur utveckling bör gå till. Jag brukar jämföra det med det som kallas mise en place i ett restaurangkök, det vill säga att man inför varje arbetsmoment ser till att ha allt man behöver i ordning framför sig. Refaktorering är att tillämpa en disciplin som möjliggör ett höggradigt iterativt utvecklingsarbete med lärandet (läs experimenterandet) i centrum.
Överfört till informationsmodellering innebär det att jag som modellerare jobbar iterativt med modellen hela tiden, och oupphörligen och outtröttligt söker ett enklare, tydligare mer korrekt uttryck. På så sätt jobbar min förståelse (min mentala modell) och modellen (den explicita modellen, den som finns på papper eller liknande) i tandem. När jag söker förbättra modellen ökar min förståelse och denna förståelse förädlar sedan modellen.
Modellen blir på så sätt vårt redskap och vår plattform för utforskandet av problemområdet och alternativa synsätt.
Part IV: Strategic Design (168 sidor)
Den fjärde delen är den verkligt intressanta, för både programmerare och informationsmodellerare. Eric Evans har sagt att han ångrar att den delen hamnade sist i boken. Läsare kanske ger upp innan de kommer dit. I synnerhet programmerare, nästan de enda som läser boken.
Den handlar om strategier man kan tillämpa för att hantera domäner som omfattar flera olika kontexter. Alltså det som möter oss när vi samtidigt modellerar olika delar av en verksamhet och behöver få ihop det på något sätt.
Jag har aldrig sett det problemet beskrivs eller hanteras någon annanstans, ändå är det en vardag för oss som informationsmodellerar verksamheter.
Evans presenterar strategierna som en serie mönster, även om han inte använder den termen. Det vill säga att han först presenterar ett problem man kan ställas inför och sedan hur man kan tänka för att hantera detta.
Några av Evans strategimönster har jag presenterat tidigare i en serie artiklar. Se följande artiklar:
- Strategimönster för informationsarkitekter del 1 – Introduktion
- Strategimönster för informationsarkitekter del 2 – Bevarande av konsistens
- Strategimönster för informationsarkitekter del 3 – Avgränsning av kontext
- Strategimönster för informationsarkitekter del 4 – Destillering av kunskap
- Strategimönster för informationsarkitekter del 5 – Den storskaliga strukturen
Jag skrev dessa artiklar för att jag tycker att informationsmodellerare skulle ha nytta av de strategier som Evans presenterat. Jag vill sprida hans insikter till de som informationsmodellerar verksamheter. Jag tycker det är nödvändigt, för jag aldrig träffat någon informationsmodellerare som har läst Evans bok. Vilket är förståelig, för vem kan tro att en bok om programmering är användbar för en informationsmodellerare?
Med detta sagt tror jag ändå att det är bäst att gå till källan. Jag tror inte jag lyckats att återge Eric Evans tankar lika bra som han själv.
Hur gick det då med Domain-Driven Design-rörelsen?
Det verkar som att DDD-rörelsen inte har kommit vidare, utan snarare hamnat i bakvatten. Varken Eric Evans eller någon annan har, mig veterligen, kommit med något som verkligen tillför något utöver vad han gjorde i sin bok. Om man söker böcker och artiklar idag hittar man nästan bara texter om programtekniska spörsmål, långt från det som verkligen var den centrala idén i boken.
Programmerare och informationsmodellerare behöver samverka
Jag är rädd för att programmerare och informationsmodellerare lever i olika världar, trots att vi jobbar med ungefär samma saker i samma organisationer och ofta bara några meter från varandra i kontorslandskapet. Låt oss bryta detta. Ett bra sätt, förutom att modellera tillsammans, är att läsa och diskutera den här boken.
Varför ska man läsa Domain-Driven Design?
För att boken är den enda källan som går på djupet med de mest centrala problemställningarna vi som modellerare har. Jag tänker på hur vi får modellen att verkligen bli plattformen för utvecklingen av den gemensamma förståelsen och det gemensamma språket. Och hur vi hanterar att vi har att göra med flera olika kontexter samtidigt.
Teori och praktik går hand i hand i denna bok. Frågeställningarna formuleras, diskuteras och besvaras på ett genomträngande, klarsynt och tydligt sätt. Därför: Läs boken. Läs den långsamt och reflekterande. Stryk under. Läs den igen!
Om du har läst den får du gärna berätta det och kommentera vad den betytt för dig.
Välkommen att maila mig på peter.tallungs@irm.se eller kommentera artikelns post på IRM:s linkedin.
Vill du prenumerera på denna artikelserie? Det innebär att du får ett nyhetsbrev, samtidigt som vi publicerar en ny artikel i ämnet informationsarkitektur, med länk till den senaste artikeln. Skriv ett mail till info@irm.se med namn och e-postadress. Skriv IA-artikelserie i ämnesraden.
