Puslespill (Puzzle). Foto: Flickr/create_joy (CC)

Utenfra fungerer en modul som en sort boks; man gir beskjeder inn og man får svar tilbake. Man vet ikke hvordan den sorte boksen kommer frem til svaret. Det gjør det enklere å forholde seg til støttefunksjoner, så man kan fokusere på den funksjonaliteten man skal lage. Jeg kaller det støttefunksjoner fordi disse funksjonene ikke er viktige; eller rettere sagt så er funksjonaliteten man arbeider med for øyeblikket mye viktigere enn en hvilken som helst annen annen modul.

Vedlikeholdbarhet

Behovet for modulbasert arkitektur oppstår når systemer blir for store til at én eller to personer kan ha oversikt over hele systemet. Da blir det viktig med vedlikeholdbare moduler av håndterbare mengder med kode.

Vedlikeholdbarhet betyr ikke at koden til stadighet må endres, noe som faktisk fungerer mot sin hensikt. Dersom modulen endres for ofte med for store endringer kan det innføre feil. Mye ny funksjonalitet kan gjøre modulen uoversiktlig og mindre vedlikeholdbar. En vedlikeholdbar modul bidrar til at resten av systemet får en tydelig måte å kommunisere med modulen på, og dersom man støter på feil så skal man klare å fikse feilen.

Eksempel på modulbasert løsning

Et svært enkelt og overordnet eksempel på en modulbasert nettbutikkløsning

Kjernen av MyWebShop kommuniserer mot eksterne komponenter over definerte grensesnitt. Det er ikke sikkert at alle komponenter har grensesnitt basert på åpne standarder, som SQL, SMTP og HTTP. Det kan være behov for å definere nye grensesnitt i bedriften. For eksempel kan kommunikasjon mot et CMS-system skje via et nytt grensesnitt vi kaller ProductService som tilbyr funksjoner som er nyttige for vår nettbutikk. På denne måten definerer vi tydelig hvilke funksjoner nettbutikken har behov for, samtidig som vi skjuler andre funksjoner som CMS-systemet tilbyr som ikke er viktige for vårt system.

Når kommunikasjon mellom moduler foregår over definerte grensesnitt, så kan moduler byttes ut med ny moduler ved behov. For eksempel kan modulen My Simple CMS byttes ut med et mer avansert og bedre CMS-system dersom nettbutikken vår blir større og får nye behov som den gamle modulen ikke kan tilby. Om den nye modulen ikke støtter det samme grensesnittet som den gamle kan man lage et veldig lite oversettingslag, kalt for et adapter, som oversetter mellom vårt eget ProductService-grensesnitt og den nye modulen.

Samhandling

Et ofte brukt tilfelle av modulbasert programvare er når data skal behandles i flere ledd. Samme grensesnitt kan brukes i front av flere forskjellige moduler. For eksempel kan et spamfilter kobles på foran e-posttjeneren slik at e-post kan filtreres før det lagres i brukerens innboks, og uønsket e-post kastes uten at brukeren ser e-posten. Fordelen med modulbasert arkitektur er klar, man får et mer oversiktlig system med komponenter som kan settes sammen og byttes ut ved behov.

Et IT-system skal løse et behov for virksomheten, eller kunden som vi kaller det. Kunden har mange behov, men man avgrenser gjerne systemet til å løse et subsett av disse behovene. Vi kaller dette for problemdomenet.

Målet med logisk arkitektur er å styrke de funksjonelle kravene, og veien til en god logisk arkitektur kan være lang. Kunden vet ikke hva det egentlige behovet er, og har ofte sin en oppfatning om hvordan løsningen skal se ut. Utviklere blir ofte veldig engasjerte og starter å lage noe de selv synes virker kult istedenfor å grave og analysere i kundens egentlige problemer.

South Park Gnomes plan

Verktøy

Det finnes flere verktøy for å analysere seg fram til en god logisk arkitektur. For å definere de funksjonelle kravene kan man skrive brukstilfeller (use cases på engelsk) som definerer hvilke brukere eller roller som skal utføre hvilke steg i en prosess for å ende opp med et ønsket resultat. Dette avdekker alternative valg som brukeren kan gjøre, for eksempel hva som skjer hvis brukeren taster en ugyldig verdi inn til systemet eller avbryter midt i prosessen. Dette dokumentet brukes for å måle om funksjonaliteten som ble avtalt er implementert og fungerer. Dette skaper en målbarhet som er viktig for at både kunde og leverandør (prosjektgruppen) skal ha felles forståelse for hva som lages og hva som er levert.

Det finnes også verktøy for å visualisere systemer, og UML er en notasjon for å visualisere systemer. Det kan visualisere brukstilfeller, flyt av data og koblinger mellom komponenter, valgmuligheter underveis i prosesser og tilstand til komponenter under gitte kriterier. Det finnes flere aspekter man kan visualiere med UML, men de nevnte er hovedsaklig de viktigste innenfor logisk arkitektur. Det handler om å modellere domenet, og komponentene navngis ofte etter begreper som brukes i virksomheten.

Domenedrevet design

En teknikk som jeg har fått sansen for er domenedrevet design (DDD), hvor fokuset rettes mot problemdomenet og det viktigste er å ha en god og dyp domenemodell på et felles språk. Dyp i at den reflekterer virksomhetens problemområde best mulig og med felles språk på tvers av programkode og de daglige funksjoner i virksomheten.

For å skape et felles språk som alle i prosjektet kjenner til og forstår betydningen av, så bør man lage en ordbok som alle gjør seg kjent med. Alle begreper fra domenemodellen bør legges inn i en slik ordbok. Ordboken skal være fri for systemtekniske begreper og skal forstås av domeneekspertene; de som kjenner virksomhetens funksjoner best.

Eksempel på domenemodell

Nedenfor vises et eksempel på en domenemodell av et bloggsystem. Det anbefales å skrive en kort tekst til figurene, da det ikke alltid er lett å forstå meningen bak en tegning. Dette er bare én av mange måter å visualisere et problem på.

Eksempel på domenemodell for en blogg

Når man får dypere forståelse av domenet lager man en ny tegning som enten erstatter en gammel tegning eller som kan supplere en eksisterende tegning. Dersom kunden fra eksempelet over også ønsker at leserne skal kunne abonnere på en strøm av blogginnlegg, så kan man lage en ny tegning som viser et søk som mates inn i en nyhetsstrømgenerator (i mangel av bedre ord).

Det finnes ingen fasit på logisk arkitektur. Alle konkurransedrevne virksomheter har særegne behov, noe de trenger for å kunne konkurrere og skille seg ut i markedet. Nettopp derfor er logisk arkitektur trolig det vanskeligste å forstå og gjennomføre innenfor IT-arkitektur.

Lykke til med neste prosjekt! Etter å ha lest dette setter du deg selvfølgelig dypere inn i kundens virksomhet og avgrenser systemets oppgaver til å løse kundens konkrete problem – ikke sant?