--- title: "Hva er Clean Architecture?" url: "https://www.bekk.christmas/post/2022/23/hva-er-clean-architecture" authors: ["Espen Ekvang"] published: "2022-12-23" updated: "2024-11-07T13:05:28Z" language: "nb-NO" type: "article" tags: ["Utvikling"] --- # Hva er Clean Architecture? Med prinsippene fra Clean Architecture oppnår vi en applikasjon med løse koblinger mellom avhengighetene og økt testbarhet. ## Kort fortalt Clean Architecture organiserer kode slik at kjernelogikken holdes uavhengig av database, API-er og andre ytre avhengigheter. Ved å la avhengighetene peke innover får man løs kobling, tydeligere ansvar mellom lagene og bedre testbarhet, vedlikehold og utvidbarhet. - **Passer for:** Utviklere som vil forstå og bruke Clean Architecture - **Fint å kunne fra før:** Grunnleggende kjennskap til applikasjonsarkitektur _Generert med KI_ Uansett hva vi utvikler er det nødvendig med ulike retningslinjer og prinsipper for at vi skal jobbe sammen og utvikle den stabile, robuste og pålitelige løsningen alle ønsker seg (til jul). Det kan være alt fra hvordan man skriver brukerhistorier, fast tidspunkt for standup, kaffepauser, testbarhet, kodekvalitet og mye mer. Et av disse settene med prinsipper finner vi i _Clean Architecture_ - det er teknikker for å organisere koden din slik at den blir lettere å teste, lettere å utvide og vedlikeholde, med løse koblinger til avhengigheter og grensesnitt. Dette er på ingen måte noe nytt og man må faktisk over 10 år tilbake for å finne frem da det først ble [omtalt](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html) av Robert C. Martin (Uncle Bob). ### Utfordringen Mange kjenner til den tradisjonelle 3-lags arkitekturen som består av 1) Grensesnitt, 2) Forretningslogikk og 3) Database, slik som figuren under illustrerer. En svakhet med denne arkitekturen er at det ikke er et tydelig skille mellom kjernen til applikasjonen (domenet og forretningsregler) og "alt annet". Dette kan føre til at man får sterke koblinger mellom ulike deler av applikasjonen og ikke minst mellom avhengigheter inn og ut av applikasjonen som database, eksterne apier og annen infrastruktur. ![3 lags arkitektur](https://cdn.sanity.io/images/ah2n1vfr/bekk-blogg-prod/580ffc15f90ed0e2c871e7f00b4be4af0ec77109-492x451.jpg) _3-lags-arkitektur_ Pilene i tegningen viser at avhengighetene ofte peker "nedover" mot databasen og strukturen på dataene i databasen og ikke minst måten man aksesserer dataene på kan bli gjenspeilet i flere deler av applikasjonen - som er unødvendig og skaper kompleksitet - spesielt med tanke på testbarhet. Ettersom det ble utviklet løsninger med 3-lags arkitekturen, vokste det frem ønsker om en bedre måter å organisere koden på. Gjennom flere år ble det definert ulike arkitekturer ([Hexagonal arkitektur](http://alistair.cockburn.us/Hexagonal+architecture), [Onion Architecture](http://jeffreypalermo.com/blog/the-onion-architecture-part-1/), [Screaming Architecture](http://blog.cleancoders.com/2011-09-30-Screaming-Architecture) m.fl.) der fellesnevneren var å oppnå være løsere kobling mellom eksterne rammeverk, grensesnitt og økt testbarhet. ### Løkringer Tilbake i [2008](https://jeffreypalermo.com/2008/07/the-onion-architecture-part-1/) ble Onion Architecture definert av Jeffrey Palermo og på samme måte som en løk er satt sammen av ringer, er arkitekturen basert på at hver av de ulike ringene representerer lagene i arkitekturen. Det viktigste her er at avhengighetene peker innover i "løken" på en sånn måte at det som er innerst i løken er tilgjengelig for alle lag utenfor, mens et lag innover aldri kan vite om noe annet enn de lagene som er lenger inn. Det man oppnår er at de innerste lagene (som typisk er domenemodellen) ikke har noen avhengigheter. Denne løkmodellen er også den mest brukte modellen for _Clean Architecture_ og ble illustrert av Robert C. Martin slik: ![Clean Architecture](https://cdn.sanity.io/images/ah2n1vfr/bekk-blogg-prod/35d11d882fe10293ead30f70989bd831cf1d0044-772x567.jpg) _clean-architecture_ Den største forskjellen fra 3-lags arkitekturen er at alle avhengigheter ligger i ytterste lag av løken. Hovedfokuset blir på logikken og ikke på hvordan dataene lagres (database) eller hvor de kommer fra (api etc). For å ta et konkret eksempel kan man se for seg at man har applikasjonslogikk som ligger i _Use Case_-laget som skal lagre data. Da vil man i _Use Case_ laget definere et grensesnitt med de metodene man forventer å kunne kalle for å få lagret dataene. Selve implementasjonen av det grensesnittet ligger dermed lenger ut og typisk i det _blå_ laget i figuren til Robert C. Martin. ### Vis meg kode! Det er fint med bokser (løkringer) og piler, men vi trenger å omsette dette til kode. Et par raske søk på internett gir oss flere eksempler på ulike tilnærminger til denne arkitekturen i forskjellige programmeringsspråk. Eksempelet jeg har satt sammen, ligger [her](https://github.com/espenekvang/christmas-architecture), og du kan bruke det som utgangspunkt dersom du ønsker å lære mer om Clean Architecture - det er selvfølgelig ingen fasit - "it depends". Eksempelet er skrevet i C# og er et veldig enkelt API med funksjonalitet for å: - legge til en pakke - hente ut en liste med alle pakker - hente ut en pakke på en gitt id Løsningen inneholder fire lag (Web, Infrastructure, Application. Domain) som har avhengighet til hverandre slik som figuren under viser. ![Avhengigheter](https://cdn.sanity.io/images/ah2n1vfr/bekk-blogg-prod/5f8afd8a7db871ea5c42086eb455fbffc1a08a43-478x727.jpg) _Avhengigheter_ Ansvaret til de fire lagene kan oppsummeres slik: - **Domain** Domeneobjekter; det innerste delen av arkitekturen og skal derfor ikke referere til noe annet lag. - **Application** Applikasjonslogikk, query og command handlere; kan bare referere til Domain - **Infrastructure** Repsitory; kan referere til Application og Domain. - **Web** Controllere, dependency injection setup ++ ; er ytterst og kan dermed kjenne til alle lag. I applikasjonslaget er det behov for å hente ut og lagre pakker. Applikasjonslaget skal derimot ikke ha noe forhold til _hvordan_ disse pakkene er lagret, det eneste som gjøres i applikasjonslaget er derfor å definere grensesnittet for å få utført disse operasjonene: ```csharp public interface IPresentRepository { public List GetAll(); public Present? FindById(int presentId); public void Save(Present present); } ``` Hvordan dette implementeres er opptil Infrastructure-laget og dermed kan man starte som i dette eksempelet med en in-memory liste uten at det påvirker applikasjonslogikken. Når man på et senere tidspunkt er klar for å implementere en faktisk database er det bare en ny implementasjon av dette grensesnittet. Et viktig poeng her er at selve implementasjonen av grensesnittet ligger i et annet lag (Infrastructure) og har `private` accessor, dermed er det umulig å dra inn den faktiske implementasjonen i applikasjonslaget som sikrer at man kun forholder seg til grensesnittet og ikke blir fristet til å dra inn avhengigheter fra andre, utenforliggende lag i arkitekturen. ### Hvor kan jeg lese mer om dette? Det er som sagt masse ressurser om dette, men jeg vil anbefale at man leser gjennom den originale posten fra Robert C. Martin som finnes [her](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html). I tillegg så har Microsoft en artikkel som beskriver flere arkitekturer deriblant Clean Architectures - den finnes [her](https://learn.microsoft.com/en-us/dotnet/architecture/modern-web-apps-azure/common-web-application-architectures). God jul!