Hva er programvarearkitektur?
Programvarearkitektur handler om å zoome ut og se på den helhetlige strukturen til kodebasen. Det er de viktigste, overordnede valgene i et system – valg som er vanskelige å endre når systemet er i produksjon.
Eksempler på arkitekturmønstre: klient-tjener, tre-lags, MVC, Microservices, Event-bus, Pipe-filter.
Høy styrke & lave koblinger
To av de viktigste prinsippene i programvaredesign og -arkitektur:
- Høy styrke (High Cohesion)
- En komponent gjør én klart avgrenset ting og gjør den godt. Den har ett eller få ansvarsområder. Gjør komponenten enklere å forstå, endre, gjenbruke og bytte ut.
- Lave koblinger (Low Coupling)
- En komponent har få avhengigheter til andre komponenter. Endringer i én komponent påvirker ikke resten. Gjør systemet lettere å teste og vedlikeholde.
Hvorfor er dette viktig?
- Høy styrke: Klart hva komponenten gjør → enklere å forstå, endre og gjenbruke
- Lave koblinger: Endringer sprer seg ikke ukontrollert → tryggere å refaktorere
- Sammen gir de oversiktlig, testbar og vedlikeholdbar kode
- Mikroservices bruker begge prinsippene: én tjeneste, én oppgave, lite avhengigheter
Vanlige arkitekturmodeller
Standalone applikasjon
All logikk og kode er samlet på én plass. F.eks. en offline mobilapp. Bra for enkle prosjekter – unngår unødvendig kompleksitet.
Klient-tjener (Client-Server)
Koden deles i to: (1) klienten som kjører i nettleseren/appen, og (2) serveren som håndterer datalagring, logikk og APIer. Skiller presentasjon fra logikk. Gir lavere kobling.
Tre-lags arkitektur (3-Tier)
En av de vanligste arkitekturene for webapplikasjoner:
- Presentasjonslag – Håndterer UI og brukerinteraksjon
- Business Logic-lag – Styrer dataflyt og forretningslogikk
- Dataaksesslag – Fasiliterer tilgang til databaser og eksterne tjenester
Hvert lag kommuniserer kun med laget over/under – høy styrke og lave koblinger.
Monolitt vs. Microservices
| Egenskap | Monolitt | Microservices |
|---|---|---|
| Kodebase | Én stor kodebase | Mange små, selvstendige tjenester |
| Deployment | Deployes samlet | Hver tjeneste deployes uavhengig |
| Skalering | Hele systemet skaleres | Kun flaskehalsen skaleres |
| Testing | Enklere (alt er lokalt) | Vanskeligere (avhengigheter mellom tjenester) |
| Teknologi | Én tech-stack | Ulik stack per tjeneste |
| Debugging | Enklere å spore | Vanskeligere å finne feilen |
| Team | Alle jobber i samme kodebase | Hvert team eier sin tjeneste |
| Kompleksitet | Enklere dataflyt | Distribuert kompleksitet |
Microservices i dybden
Microservices er en arkitekturstil der applikasjonen deles opp i mange små, selvstendige tjenester. Hver tjeneste:
- Gjør én avgrenset oppgave (høy styrke)
- Kommuniserer via standardiserte protokoller (REST, gRPC, meldingskø)
- Eier sine egne data (ingen delt database)
- Kan deployes og skaleres uavhengig av de andre
Fordeler
Fordeler
- Skalerbarhet – kun flaskehalsen skaleres
- Modularitet – uavhengige team per tjeneste
- Teknologimangfold – ulike språk/rammeverk per tjeneste
- Resiliency – resten kjører selv om én er nede
- Enklere eksperimentering – bytt ut én tjeneste uten å påvirke resten
Ulemper
- Vanskelig å identifisere hvilken tjeneste en feil stammer fra
- Deployment-kompleksitet (Kubernetes, service mesh)
- Datakonsistens på tvers av tjenester
- Testing av flyt som spenner over tjenester
- Kaotisk med parallelle versjoner av samme tjeneste
Konkret eksempel: Handelssystem
Et handelssystem med separate tjenester: Order-service, Fee-service, Market-service, Account-service.
- Fee-tjenesten kan programmeres i et annet språk enn resten
- Market-tjenesten kan oppdateres uten å påvirke Order-tjenesten
- Hvis Fee-service er nede, kan resten av systemet fortsatt ta imot ordrer
- Transaksjonsdatabasen eies eksklusivt av Account-service
MVC-mønsteret
MVC (Model-View-Controller) deler en interaktiv applikasjon i tre deler:
- Model
- Inneholder all data som vises i applikasjonen, samt annen data som er viktig for prossessering. Forretningslogikk og tilstand.
- View
- Viser frem modeller og data til brukeren gjennom et grafisk brukergrensesnitt. Kun presentasjon.
- Controller
- Styrer informasjonsflyten. Tar input fra bruker, henter/sender data, og oppdaterer Model og View.
Brukt av Django, Ruby on Rails, Spring MVC og mange web-rammeverk. Gir høy styrke og lave koblinger.
Andre arkitekturmønstre
Master-slave
En «master» delegerer oppgaver til «slaves». Brukes i databasereplikering (master er sannhetskilden, slaves synkroniserer). Gir høyere kapasitet og mulighet for separat testing av deler.
Pipe-filter
Data strømmer gjennom en sekvens av filter-noder som prosesserer og transformerer dataene. Brukt i kompilatorer, bildeprosessering og e-postsending.
Event-bus
Komponenter publiserer meldinger til en sentral event-bus. Andre komponenter abonnerer på hendelser de er interessert i. Løs kobling mellom avsender og mottaker.
Broker
En mellommann (broker/API) håndterer kommunikasjon mellom tjenester som ikke kjenner hverandre. Gjør det mulig å bytte ut systemer uten at klienten merker det.
Peer-to-peer
Alle noder er likestilte og kommuniserer direkte med hverandre – ingen sentral tjener. Brukt i distribuerte systemer, fildelingsnettverk og blokkjeder. Høy resiliency: systemet fungerer selv om noen noder er nede.