En maritim platform bygget i rene lag

Situation. Produktet skulle være en maritim platform — professionelt netværk, virksomhedsanmeldelser, sponsoreret uddannelse — og det var et ungt produkt, hvilket er en høflig måde at sige på, at kravene ville flytte sig en hel del. Det, der skulle undgås, var en arkitektur, hvor en ændret forretningsregel betød, at man skulle ind og rette i frontenden, API’et og databasen på én gang. I en lille kodebase, der vokser hurtigt, er det netop den slags kobling, der gør en ændring på to linjer til en hel eftermiddags arbejde.

Opgave. Arkitektrollen indebar én beslutning, der skulle træffes på forhånd: hvor hver slags logik hørte hjemme, med grænser, der var tydelige nok til at holde under pres i stedet for at flyde ud, første gang nogen havde travlt.

Handling. Det endte med tre lag med én opgave hver. Next.js‑frontenden står for præsentation og interaktivitet og intet andet. Go‑API’et — Huma oven på Fiber — er bevidst tyndt: det router, validerer requesten, står for sikkerhedsfiltreringen og orkestrerer, men det rummer slet ingen forretningslogik. Al forretningslogikken ligger i PostgreSQL‑funktioner, som samler hele resultatet og returnerer det, så API’et blot sender det videre. Når en regel ændrer sig, ændrer den sig altså i ét lag, i SQL, og de to andre behøver ikke at vide det. Grænserne blev skrevet ned og derefter håndhævet i review, for en konvention, som ingen holder øje med, holder op med at være en konvention.

Resultat. Systemet forblev til at overskue. Forretningslogikken ligger ét sted, som man faktisk kan gennemgå, API’et er en kedelig adapter i ordets gode forstand, og frontenden er ligeglad, når skemaet ændrer sig under den. Det var den adskillelse, der gjorde det muligt at blive ved med at skrue nye funktioner på produktet, uden at arkitekturen i stilhed rådnede.