Softwarearkitektur

Når man taler om softwarearkitektur, handler det i bund og grund om at organisere koden og systemets overordnede struktur, så det bliver nemmere at udvikle, vedligeholde, teste og videreudvikle applikationen over tid. Arkitektur er et sæt principper og beslutninger, der hjælper med at placere koden de rette steder, vælge passende mønstre og definere tydelige grænser mellem forskellige dele af systemet.

I mindre projekter (for eksempel under en skoleopgave eller en kort POC – “Proof of Concept”) har man ofte ikke brug for store, avancerede arkitekturovervejelser. En hurtig applikation med et par klasser, en database og en brugergrænseflade kan sagtens laves uden at tænke synderligt over lag eller designmønstre.

Udfordringen opstår, når projektet vokser, og der skal tilføjes mere funktionalitet. Hvis koden er blandet sammen (f.eks. forretningslogik blandet med databaser og brugerflade i de samme klasser), bliver det svært at rette fejl, lave ændringer eller tilføje nye funktioner uden at ødelægge andet.

God arkitektur fremmer genanvendelse af kode, fordi man strukturerer projektet, så klasser og metoder får klare ansvarsområder (single responsibility). Testbarhed hænger også sammen med arkitektur: Hvis dine klasser er tæt koblede (f.eks. de direkte afhænger af eksterne systemer eller databaser), er det svært at teste dem isoleret. Med en ordentlig opdeling kan du nemmere mocke eller stube afhængigheder i dine tests.

At tænke over arkitektur er en investering i begyndelsen af et projekt. Man skal træffe visse overordnede beslutninger om struktur, men til gengæld sparer man tid og frustration senere, når projektet bliver større. Jo mere kompleks din applikation er, desto større gevinst vil du se ved at have en velovervejet arkitektur.

Helt overordnet kan man sige, at arkitektur handler om at dele og strukturere koden, så den bliver nemmere at forstå, vedligeholde, teste og udvide.

Stilarter

Der findes en række forskellige “skoler” eller “stilarter” inden for softwarearkitektur, og hvilken stil man vælger, afhænger meget af projektets størrelse, historik, kompleksitet og domæne. De to allermest almindelige er:

• Monolit
• Lagdelt arkitektur

Monolit

En monolit er en betegnelse for et system, hvor alt koden ligger samlet i ét enkelt projekt (eller få projekter), og hvor der ikke nødvendigvis er en klar adskillelse mellem forskellige ansvarsområder. Tænk på en stor applikation, hvor:

• Databaselogik, brugersessioner, forretningsregler og brugergrænseflade er bundet tæt sammen.
• Ændrer du i ét område af koden, kan det hurtigt give uforudsete konsekvenser i andre dele af systemet.

Men der kan være fordele ved monolitten. Den er enkel at sætte op, særligt til mindre projekter, og du har kun ét sted at lede efter kode.

Ulemperne er til gengæld mange.

• Skalerbarheden kan være begrænset, fordi du ikke kan dele det op i selvstændige enheder.
• Vedligeholdelse bliver svært, når koden vokser, fordi alt hænger sammen.
• Udrulning (deployment) kan være tung: selv små ændringer kræver, at hele applikationen genudgives.

En monolit kan altså være glimrende til små projekter eller prototyper, men bliver ofte en udfordring i større projekter med mange udviklere og hyppige ændringer.

Lagdelt arkitektur

I den lagdelte arkitektur (ofte kaldet 3-lags arkitektur) deler vi typisk applikationen op i mindst tre lag:

1. Præsentationslaget (UI-laget)
   Her håndteres alt, der har med brugergrænsefladen at gøre, uanset om det er en web-, mobil- eller desktop-app.
2. Forretningslaget (Business Logic Layer)
   Her bor den logik, der beskriver, hvordan systemet skal fungere: regler, beregninger og arbejdsgange.
3. Dataadgangslaget (Data Access Layer)
   Her har vi koden, der håndterer databasetilgange, filer og eksterne API’er.

Formålet er at sikre, at præsentationen ikke ved for meget om, hvordan data bliver hentet eller behandlet, og at forretningslogikken er isoleret fra de tekniske detaljer om databaseopkobling. I koden kan det for eksempel se sådan ud:

• Et Data Access-projekt i din løsning (solution) indeholder klasser, der taler direkte med en database, fx Repository-klasser eller EF Core-kontekster (DbContext).
• Et Business-projekt rummer forretningsobjekter (entiteter) og services, der udfører regler eller beregninger.
• Et Presentation-projekt er måske et ASP.NET Core-projekt eller en WPF-applikation, der præsenterer data for brugeren og kalder metoder fra forretningslaget.

Der er mange fordele ved den lagdelte arkitektur:

• Klar opdeling gør det lettere at vedligeholde og teste de forskellige dele af systemet.
• Du kan ændre brugergrænseflade eller database uden at skulle omskrive hele applikationen.

Men der er også ulemper:

• Flere lag og projekter kan opleves som mere komplekst at sætte op i starten, især for mindre projekter.
• Kræver en vis disciplin og forståelse, så man ikke begynder at “blande” ansvarsområder alligevel.

Softwarearkitektur er en måde at sikre, at din applikation er struktureret fornuftigt fra start, så den er nem at arbejde med på længere sigt. Det handler ikke kun om at skrive “pæn” kode, men også om at sikre skalerbarhed, testbarhed og vedligeholdelsesvenlighed.

• Monolitten er enkel at komme i gang med, men kan hurtigt vokse sig uoverskuelig.
• Den lagdelte arkitektur giver en mere robust opdeling af ansvar, så det bliver lettere at overskue og videreudvikle dit projekt.

Stilarter og mønstre

Ud over de overordnede stilarter findes der en række mønstre og principper, der kan hjælpe med at strukturere din kode og sikre, at den er nem at vedligeholde og udvide. Nogle af de mest kendte er:

• SOLID-principperne
  En række principper, der beskriver, hvordan klasser bør designes, så de er nemme at forstå, teste og udvide.
• Design Patterns Genanvendelige løsninger på almindelige problemer, fx Singleton, Factory, Observer og Strategy.