Hvor uheldig er egentlig en kobling?

14. mars 2024

I mitt forrige innlegg skrev jeg om koblinger i programvare, hva de egentlig er og hvilke ulemper og fordeler de gir. I dette innlegget ser jeg videre på ulempene koblinger gir, og beskriver en modell for å vurdere hvor store disse er. Modellen er hentet fra Vlad Khononov sin presentasjon og kommende bok, Balancing Coupling in Software Design. 

I modellen klassifiseres koblinger i tre dimensjoner: styrke, avstand og endringstakt. Nedenfor beskrives disse dimensjonene, samt hvordan de kan brukes for å finne ut om ulempene med en kobling er store eller små.

Styrke

Styrken i en kobling mellom to moduler av programvare følger av hvilken av de fire beskrivelsene nedenfor som beskriver koblingen best. Modul kan her bety alt fra noe så lite som en metode i en klasse, til så store ting som hele IT-løsninger. 

Inngripende kobling (intrusive coupling) 

Dette er den sterkeste typen kobling. Her har koblingen gjort seg avhengig av interne detaljer i implementasjonen, bruker private funksjoner eller tilsvarende. Koblingen fra modul K til modul S bruker altså deler av modul S som det ikke er ment at noen andre skal bruke. Da er det stor fare for at det kan skje endringer i modul S som skaper store problemer for modul K. 

Funksjonell kobling 

Her har de to modulene fått en tett funksjonell kobling, altså at en funksjonell endring i en av modulene krever at den andre modulen også endrer sin funksjonalitet. Dette er et symptom på feil inndeling i moduler (low cohesion), og er en ganske sterk kobling. 

Modell-kobling 

I motsetning til en funksjonell kobling, er koblingen her bare mot datamodellen. Dette er en svakere kobling enn den funksjonelle, og kun endringer i selve datamodellen i den ene modulen kan medføre krav til endring i den andre modulen. Like fullt er datamodellen en svært sentral del av en modul, og det at andre moduler gjør seg avhengig av detaljer i den, vil gjøre det mer tungvint/risikabelt å gjøre endringer i modellen. 

Kontrakts-kobling 

I en kontrakts-kobling er det laget en egen modell, ofte kalt DTO, og et eget grensesnitt for integrasjon mot andre moduler. Da har modulen større frihet til å gjøre endringer i sin interne datamodell uten at det påvirker andre moduler, og tilsvarende med interne funksjoner. Dette er den svakeste koblingen av de fire. 

Avstand 

Avstanden mellom modulene som har en kobling kan ha stor praktisk betydning for hvor store ulemper koblingen gir. Avstand her er ikke fysisk avstand, men i stedet et uttrykk for hvor mye koordinering som må til for å få gjennomført endringer på begge sider av en kobling. 

Om koblingen er mellom to moduler i samme kodebase er avstanden veldig liten. Å endre i begge disse modulene samtidig er helt naturlig, og ingen koordinering trengs utover blant de som programmerer endringen.  

Hva om koblingen er mellom to mikrotjenester? Da kan det være at endringene i disse må koordineres, kanskje må det brukes expand-contract-pattern for å gjennomføre endringen på en trygg måte. Likevel er de som må koordinere arbeidet gjerne på samme team, og koordineringen er normalt ganske enkel å gjennomføre. 

Hva så om koblingen er mellom to forskjellige løsninger i samme organisasjon? Eller enda verre, mellom to løsninger i forskjellige organisasjoner? Sistnevnte kan være svært krevende å få gjennomført, og åpenbart svært mye tyngre enn å endre i moduler som ligger i samme kodebase. 

Endringstakt 

Ulempene med koblinger utløses gjerne når det skal gjøres endringer. Hvis endringer skjer svært sjeldent, kan en kobling ha både høy styrke og lang avstand, men likevel skape lite ulemper totalt sett. På samme måte kan en kobling ha både lav styrke og kort avstand, men likevel skape store problemer hvis den har veldig høy endringstakt. 

Smerten ved en kobling 

Hvordan skal så disse tre dimensjonene, styrke, avstand og endringstakt, brukes for å finne hvor uheldig en kobling er? Sentralt i Khononovs modell er følgende ligning: 

 

Smerte = Styrke * Avstand * Endringstakt 

 

Smerte er altså ulempen som koblingen gir, eller smerten ved å forvalte systemet som har koblingen. Styrke, endringstakt og avstand angis med en verdi mellom 0 og 1. Da ser vi at hvis en av faktorene er veldig nærme null, kan smerten være lav selv om de to andre faktorene er høye.  

Denne modellen synes jeg hjelper veldig med å kunne gjøre konkrete og gode vurderinger av koblinger i programvare, og slik også bidra til å avmystifisere disse koblingene som arkitekter snakker om hele tiden.

Om du vil lære mer om modellen anbefaler jeg å se en av presentasjonene til Khononov, f.eks. denne fra DDD Europe 2023.