Arkitekturprofil
Layer-3-arkitektur i overblik
Layer-3-arkitektur er for os ikke et arkitekturord til slides, men et meget praktisk greb mod monolitter, der er vokset over tid. Adskillelsen af client, forretningslogik og dataadgang sikrer, at udvidelser, tests, portaler, services og nye platforme ikke hver gang skal sprænge de samme tætte koblinger.
UI forbliver UI
Brugerflader skal føre brugere, ikke i det skjulte bære hele domænelogikken. Først dermed bliver betjening, tests og nye frontends håndterbare.
Fagregler hører hjemme i midten
Den egentlige faglige substans ligger i regler, tilstandsskift, godkendelser og plausibilitetskontroller. Netop denne midte skal forblive fælles anvendelig og sporbar.
SQL og persistens forbliver udskiftelige
Den, der indkapsler dataadgang rent, forhindrer, at hvert nyt krav direkte spreder tabelviden ud i brugerflader eller services.
Hvorfor Layer-3 i hverdagen tager så meget tryk ud af systemet
Mange systemer, der er vokset over tid, ser ved første øjekast bare teknisk uordentlige ud. Den egentlige skade viser sig senere: En ny portal har brug for den samme fagregel, en service skal behandle den samme tilstand korrekt, en ny client skal læse de samme data, og pludselig bliver det synligt, at reglerne lever spredt ud over formularer, SQL og hjælperutiner.
Det er præcis her, Layer-3 hjælper. Når UI, forretningslogik og dataadgang adskilles bevidst, opstår der en faglig midte, som kan forsyne flere adgange rent. Nye brugerflader, REST-servere, testcases eller integrationer behøver så ikke længere at arbejde mod en monolit, men kan koble sig på definerede ansvarsområder.
Det gør ikke systemer automatisk mindre, men markant mere læsbare. Fejl kan lokaliseres renere, udvidelser planlægges mere målrettet, og datapaths moderniseres mere kontrolleret. Især i kombinationen af modernisering af eksisterende løsninger, services og multiplatform er det ofte den afgørende forskel mellem planbar videreudvikling og konstant efterarbejde.
Styrker, svagheder og typiske misforståelser
Hvad der gør Layer-3 stærk
Arkitekturen skaber læsbarhed, genbrug, bedre testbarhed og mere ro ved nye krav. Især systemer, der er vokset over tid, får dermed igen teknisk luft.
Hvor man kan dreje forkert
Layer-3 bliver værdiløs, hvis der kun opstår nye projektlag, men de egentlige regler fortsat forbliver skjult i UI-koden eller i direkte SQL. Så er det et label i stedet for struktur.
Hvad man realistisk skal se
En god lagdeling kræver disciplin. Den gør ikke systemer overfladisk set enklere i starten, men senere markant mere økonomiske. Netop derfor er den især relevant for systemer med levetid og vækst.
Hvordan vi konkret anvender Layer-3
For os er Layer-3 det strukturelle fundament for moderne virksomhedssoftware. Den gør det muligt, at desktop, REST-server og services, nye clients og datamodernisering ikke arbejder imod hinanden. Derfor starter god arkitektur for os ikke med et framework, men med klare ansvarsområder mellem UI, logik og persistens.
Hvis en eksisterende løsning allerede er vokset kraftigt, er siden Delphi-modernisering som regel den rigtige nabo. Hvis arkitekturen sigter mod flere desktop-mål, fører vi den linje videre med Delphi Multiplatform.
FAQ om Layer-3-arkitektur
Layer-3 er ikke et lærebogsord, men et meget praktisk svar på monolitter, der er vokset over tid, modstridende udvidelser og dyre koblinger i hverdagen.
Hvorfor er Layer-3 så vigtig i virksomhedsapplikationer?
Fordi det først er den rene adskillelse af UI, forretningslogik og dataadgang, der sikrer, at udvidelser, tests, services og nye platforme ikke fejler direkte på monolitten.
Er Layer-3 kun fornuftig i store projekter?
Nej. Især mellemstore systemer har stor gavn af det, fordi senere krav kan kobles på markant mere kontrolleret.
Hvad er den mest almindelige fejl ved Layer-3?
At man kun tegner lag formelt, men fortsat skjuler de egentlige regler i UI-koden eller direkte i særlige SQL-stier. Så findes opbygningen kun på slides, ikke i systemet.
Læs flere spørgsmål samlet
Disse korte svar bliver her på siden. På den centrale FAQ-landingpage indplacerer vi emnet desuden i sammenhæng med arkitektur, modernisering, platforme og drift.