Implementering av en ren arkitektur med Nest.JS

Denne artikkelen er for entusiaster som streber etter å skrive ren, skalerbar og enda viktigere refaktorerbar kode. Det vil gi en idé om hvordan Nest.JS kan hjelpe oss med å skrive ren kode og hvilken underliggende arkitektur den bruker.

Implementering av en ren arkitektur med Nest.JS vil kreve at vi først forstår hva dette rammeverket er og hvordan det fungerer.

Nest eller Nest.JS er et rammeverk for å bygge effektive, skalerbare Node.js-applikasjoner (server-side) bygget med TypeScript. Den bruker Express eller Fastify og tillater et abstraksjonsnivå for å gjøre det mulig for utviklere å bruke en rikelig mengde moduler (tredjepart) i koden deres.

La oss grave dypere inn i hva denne rene arkitekturen handler om. 

Vel, dere har kanskje alle brukt eller i det minste hørt om MVC-arkitektur. MVC står for Model, View, Controller. Tanken bak dette er å dele opp prosjektstrukturen vår i 3 forskjellige seksjoner.

1. Modell: Den vil inneholde objektfilen som tilordnes med Relasjon/Dokumenter i DB.

2. Kontroller: Det er forespørselsbehandleren og er ansvarlig for implementeringen av forretningslogikk og all datamanipulering.

3. Vis: Denne delen vil inneholde filer som er opptatt av visning av data, enten HTML-filer eller noen malmotorfiler.

For å lage en modell trenger vi et slags ORM/ODM-verktøy/modul/bibliotek å bygge den med. For eksempel, hvis du bruker modulen direkte, la oss si "oppfølger", og deretter bruke det samme for å implementere pålogging i kontrolleren din og gjøre kjernevirksomhetslogikken din avhengig av "oppfølgeren". Nå, la oss si etter 10 år, er det et bedre verktøy på markedet som du vil bruke, men så snart du erstatter oppfølgeren med det, må du endre mange linjer med kode for å forhindre at det bryte. Du må også teste alle funksjonene igjen for å sjekke om de er implementert vellykket eller ikke, noe som også kan kaste bort verdifull tid og ressurser. For å overvinne denne utfordringen kan vi bruke det siste prinsippet til SOLID som er avhengighetsinversjonsprinsippet, og en teknikk som kalles avhengighetsinjeksjon for å unngå slikt rot.

Fortsatt forvirret? La meg forklare i detalj.

Så, det avhengighetsinversjonsprinsippet sier med enkle ord, er at du lager din kjernevirksomhetslogikk og bygger deretter avhengighet rundt den. Med andre ord, frigjør kjernelogikken og forretningsreglene fra enhver form for avhengighet og modifiser de ytre lagene på en slik måte at de er avhengige av kjernelogikken din i stedet for din logikk avhengig av dette. Det er det som er ren arkitektur. Det tar ut avhengigheten fra kjernevirksomhetslogikken din og bygger systemet rundt det på en slik måte at de ser ut til å være avhengige av det i stedet for at det er avhengig av dem.

La oss prøve å forstå dette med diagrammet nedenfor.

kilde: Ren arkitekturkjegle 

Du kan se at vi har delt arkitekturen vår i 4 lag:

1. Enheter: I kjernen er entiteter modellene (Enterprise-regler) som definerer bedriftsreglene dine og forteller hva applikasjonen handler om. Dette laget vil neppe endre seg over tid og er vanligvis abstrakt og ikke tilgjengelig direkte. For eksempel har hver applikasjon en 'bruker'. Hvilke alle felt brukeren skal lagre, deres typer og relasjoner til andre enheter vil omfatte en Entitet.

2. Brukstilfeller: Den forteller oss hvordan vi kan implementere virksomhetsreglene. La oss ta eksemplet med brukeren igjen. Nå vet vi hvilke data som skal betjenes, use casen forteller oss hvordan vi skal operere på disse dataene, som at brukeren vil ha et passord som må krypteres, brukeren må opprettes og passordet kan endres når som helst gitt tidspunkt osv.

3. Kontrollere/gatewayer: Dette er kanaler som hjelper oss å implementere brukstilfellene ved hjelp av eksterne verktøy og biblioteker ved bruk av avhengighetsinjeksjon.

4. Eksterne verktøy: Alle verktøyene og bibliotekene vi bruker for å bygge logikken vår kommer under dette laget, f.eks. ORM, Emailer, Kryptering, etc.

Verktøyene vi bruker vil avhenge av hvordan vi kanaliserer dem til brukssaker, og i sin tur vil brukstilfeller avhenge av enhetene som er kjernen i virksomheten vår. På denne måten har vi snudd avhengigheten fra utover til innover. Det er hva avhengighetsinversjonsprinsippet til SOLID innebærer.

Ok, nå har du skjønt kjernen av Nest.JS og forstått hvordan ren arkitektur fungerer. Nå oppstår spørsmålet, hvordan disse to henger sammen?  

La oss prøve å forstå hva som er de tre byggeklossene til Nest.JS og hva hver av dem gjør.

1. moduler: Nest.JS er strukturert på en slik måte at vi kan behandle hver funksjon som en modul. For eksempel kan alt som er knyttet til brukeren, slik som modeller, kontrollere, DTO-er, grensesnitt osv., separeres som en modul. En modul har en kontroller og en haug med leverandører som er injiserbare funksjoner som tjenester, orm, e-poster, etc.

2. Controllers: Kontrollere i Nest.JS er grensesnitt mellom nettverket og logikken din. De brukes til å håndtere forespørsler og returnere svar til klientsiden av applikasjonen (for eksempel kall til API).

3. Leverandører (tjenester): Leverandører er injiserbare tjenester/funksjoner som vi kan injisere inn i kontrollere og andre leverandører for å gi fleksibilitet og ekstra funksjonalitet. De abstraherer enhver form for kompleksitet og logikk.

Å oppsummere,

• Vi har kontrollere som fungerer som grensesnitt (tredje lag med ren arkitektur)
• Vi har leverandører som kan injiseres for å gi funksjonalitet (fjerde lag med ren arkitektur: DB, enheter, etc.)
• Vi kan også opprette tjenester og depoter for å definere vårt bruksområde (2nd Layer)
• Vi kan definere enhetene våre ved å bruke DB-leverandører (1st Layer)

Konklusjon:

Nest.JS er et kraftig Node.JS-rammeverk og det mest kjente maskinskriftet som er tilgjengelig i dag. Nå som du har lav ned på dette rammeverket, må du lure på om vi kan bruke det til å bygge en prosjektstruktur med en ren arkitektur. Vel, svaret er -Ja! Absolutt. Hvordan? Jeg skal forklare i neste serie av denne artikkelen. 

Inntil da, følg med!

Om forfatteren:

Junaid Bhat jobber for tiden som teknisk leder i Mantra Labs. Han er en teknologientusiast som streber etter å bli en bedre ingeniør hver dag ved å følge industristandarder og innrette seg mot en mer strukturert tilnærming til problemløsning. 

Les vår siste blogg: Golang-Beego Framework og dets applikasjoner

Det er verdt å levere kunnskap i innboksen