Forstå Clean Architecture

Mål med Clean Architecture

Clean Architecture har som mål å skape programvare som er enkel å forstå, vedlikeholde og teste. Den legger vekt på separasjon av bekymringer og opprettelse av godt definerte grenser mellom forskjellige deler av applikasjonen. Denne separasjonen tillater enklere testing av individuelle komponenter.

Fordeler med Clean Architecture

• ➤ Rammeverksuavhengighet: Kan brukes med ASP.NET (Core), Java, Python, etc., uten å være avhengig av spesifikke programvarebiblioteker eller proprietære kodebaser.
• ➤ Testbarhet: Kan brukes med ASP.NET (Core), Java, Python, etc., uten å være avhengig av spesifikke programvarebiblioteker eller proprietære kodebaser.
• ➤ UI-uavhengighet: Logikk holdes utenfor UI, noe som gjør det enkelt å bytte teknologier, f.eks. fra Angular til React eller Blazor.
• ➤ Databaseuavhengighet: Skiller data-tilgangsbekymringer klart, og gjør det lettere å endre fra SQL Server til CosmosDB.
• ➤ Uavhengighet fra eksterne systemer: Kjernen er fullstendig isolert fra omverdenen, noe som sikrer lang levetid og enkel oppdatering.
• ➤ Løs kobling: Fremmer løs kobling mellom komponenter og lag, noe som forbedrer vedlikeholdbarhet og skalerbarhet.

Clean Architecture: Det store bildet

• 1. Forretningslogikk og applikasjonsmodell i sentrum: Sikrer at viktige aspekter av programvaren er uavhengige og godt definerte.
• 2. Inverterte avhengigheter: Forretningslogikk avhenger ikke av data-tilgang eller infrastrukturbekymringer; i stedet avhenger infrastrukturen av Applikasjonskjernen.
• 3. Tydelige abstraksjoner i Applikasjonskjernen: Definerer klare abstraksjoner (grensesnitt) som representerer viktige kontrakter.
• 4. Implementering i Infrastruktur-laget: Konkrete implementeringer finnes i Infrastruktur-laget, som håndterer data-tilgang, eksterne tjenester, osv.
• 5. Innoverende flyt av avhengigheter: Alle avhengigheter flyter innover mot Applikasjonskjernen, og sikrer streng separasjon av bekymringer.

Lag i Clean Architecture

• ➤ Domenelag: Kjernen i arkitekturen, implementerer forretningslogikk uten avhengighet til andre lag.
• ➤ Applikasjonslag: Midterste lag, håndterer data mellom domenet og presentasjons-/infrastruktur-lagene.
• ➤ Infrastruktur-lag: Inneholder klasser for tilgang til eksterne ressurser som filsystemer, webtjenester og databaser.
• ➤ Presentasjonslag: UI-kode, bruker ASP.NET Core for å bygge grensesnitt.

Domain Driven Design (DDD)

Domain-Driven Design (DDD) er et sett med prinsipper og mønstre for å designe programvare som fokuserer på kjerneområdet og dets logikk. DDD legger vekt på samarbeid mellom tekniske og domeneeksperter for å iterativt forbedre en konseptuell modell som adresserer komplekse forretningskrav. Nøkkelkonseptene i DDD inkluderer:

• Enheter:	Objekter med en distinkt identitet som går gjennom forskjellige tilstander i systemet.
• Verdiobjekter:	Immutable objekter som representerer et beskrivende aspekt av domenet uten konseptuell identitet.
• Aggregater:	En klynge av domeneobjekter som behandles som en enkelt enhet for datamodifikasjoner.
• Repositorier:	Mekanismer for å kapsle inn lagring, henting og søkebehavior, etterlignende en samling av objekter.

Testing i Clean Architecture

Testing i Clean Architecture involverer testing av hvert lag uavhengig for å sikre at alle komponenter fungerer korrekt og interagerer riktig med hverandre. Dette er et svært viktig steg og reduserer kompleksiteten betydelig.

1. ➤ Mocking: Opprette objekter som simulerer oppførselen til ekte objekter. I dette tilfellet kan du mocke dine databaserepositorier uten den faktiske implementeringen.
2. ➤ Avhengighetsinjeksjon: Passere avhengigheter (som repositorier) til dine brukstilfeller eller tjenester for å gjøre dem lettere å utføre enhetstesting.
3. ➤ Isolasjon: Sørge for at hver test er uavhengig og ikke er avhengig av tilstanden eller dataene fra andre tester.

Implementering av Clean Architecture

• 1. Konfigurasjon av Domenelag: Definer enheter, enums, unntak, grensesnitt og typer.
• 2. Konfigurasjon av Applikasjonslag: Skriv forretningslogikk og tjenestegrensesnitt, og oppretthold løs kobling.
• 3. Konfigurasjon av Infrastruktur-lag: Implementer data-tilgang og interaksjon med eksterne ressurser basert på Kjernegrensesnitt.
• 4. Konfigurasjon av Presentasjonslag: 4. Konfigurasjon av Presentasjonslag:

Prinsipper å Følge

1. Separasjon av Bekymringer:	Unngå å blande forskjellige kodeansvar i samme metode/klasse/prosjekt.
2. Enkeltansvar:	Hver modul/komponent skal ha kun én grunn til å endre seg.
3. Ikke Gjenta Deg Selv (DRY):	Unngå duplisert kode eller logikk.
4. Inverterte Avhengigheter:	Høynivåpolitikker skal ikke være avhengige av lavnivådetaljer; bruk avhengighetsinjeksjon for å fremme løs kobling.

Konklusjon

Clean Architecture gir et solid grunnlag for å bygge mikrotjenester ved hjelp av .NET Core Web API. Ved å følge prinsippene for separasjon av bekymringer og avhengighetsinversjon kan utviklere lage skalerbare, vedlikeholdbare og testbare applikasjoner. Å ta i bruk Clean Architecture sikrer et solid fundament for de stadig skiftende kravene i moderne programvareutvikling.

Lær mer ved å besøke vår GitHub