Applikasjonsarkitektur er jo kanskje et tungt og vanskelig ord som ikke engang lar seg legge i Wordfeud eller Scrabble, så la oss grave litt i grunnen.

Dette kan f.eks. betegne arkitekturen til én applikasjon eller et system, gjerne med et snedig diagram med bokser og piler som betegner flyt, men kan også være de mer overordnede linjene i en applikasjon.

Det kan f.eks. være struktur (tenk f.eks. på frontend-applikasjoner der koden kan være organisert funksjonalitetsbasert (slik at alle filer som tilhører samme funksjonalitet ligger plassert sammen) eller lagbasert (hver type ansvarsnivå gruppert sammen), tilsvarende moduler, sikkerhet, eller andre overordnede prinsipper.

Det er ofte ikke et helt tydelig skille mellom arkitektur og
kodestruktur/design patterns.

I løpet av de siste årene har vi sett et bredt spekter av ideer angående arkitekturen til systemer. Dette inkluderer f.eks. Clean Architecture, som også kan betegnes som heksagonal arkitektur, eller løkarkitektur (Onion Architecture).

Selv om disse arkitekturene varierer noe i detaljer, er de veldig like. De har alle det samme målet, nemlig å skille ansvarsområder. De oppnår denne separasjonen ved å dele programvaren opp i lag. Hvert system har minst ett lag for forretningsregler, og ett for grensesnitt.

Vi utviklere som er litt eldre, eller “litt erfarne” som det også kan kalles, husker godt tilbake til tiden Design Patterns var i vinden, godt backet opp av boken “Gang of Four”. Alt skulle være patterns, og vi skulle selvsagt unngå det helt motsatte, anti-patterns.

Når man tenker over det, kan man si at selv den enkleste if-setning er et pattern .

Selv om det kanskje er mindre fokus på patterns enn det var på midten av 2000-tallet, har endringer i språk og rammeverk inkorporert mange av endringene. Builder-patternet f.eks. har mer eller mindre blitt en standard måte å løse objektoppretting på i Java- og Kotlin-verdenen.

Vi tar et par andre enkle og nokså kjente eksempler:

Singleton Pattern

• Eldre Java-eksempel:
  • Man måtte lage en privat konstruktør, en statisk instansvariabel, og en statisk metode for å aksessere denne instansen

class Singleton {
    private static Singleton instance;
    private Singleton() {}
    public static Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

Moderne løsning i Kotlin:

object Singleton

Builder pattern

Det kjente patternet for å konstruere kompliserte objekter har også gjennomgått en reise.
Beklager denne nokså omfattende Java-koden:

public class Product {
    private String name;
    private int price;

    private Product(Builder builder) {
        this.name = builder.name;
        this.price = builder.price;
    }

    public static class Builder {
        private String name;
        private int price;

        public Builder setName(String name) {
            this.name = name;
            return this;
        }

        public Builder setPrice(int price) {
            this.price = price;
            return this;
        }

        public Product build() {
            return new Product(this);
        }
    }
}

I Kotlin får man en mye enklere implementasjon med apply og named parameters .

data class Product(var name: String = "", var price: Int = 0) 

val product = Product().apply { name = "Laptop" price = 1500}

Neste gang noen i ditt nærvær nevner ordet applikasjonsarkitetur, ikke nødvendigvis tenk at det må være stort, men at også kan være smått. Alle utviklere kan være arkitekter på sitt nivå.

Husk at god applikasjonsarkitektur er grunnlaget for robuste, skalerbare systemer som tåler tidens tann og tilpasser seg fremtidige behov. Enhver utvikler kan bidra på sin måte!