Implementering af en ren arkitektur med Nest.JS

Denne artikel er for entusiaster, der bestræber sig på at skrive ren, skalerbar og endnu vigtigere gendannes kode. Det vil give en idé om, hvordan Nest.JS kan hjælpe os med at skrive ren kode, og hvilken underliggende arkitektur den bruger.

Implementering af en ren arkitektur med Nest.JS kræver, at vi først forstår, hvad denne ramme er, og hvordan den fungerer.

Nest eller Nest.JS er en ramme til at bygge effektive, skalerbare Node.js-applikationer (server-side) bygget med TypeScript. Det bruger Express eller Fastify og tillader et abstraktionsniveau for at gøre det muligt for udviklere at bruge en rigelig mængde moduler (tredjepart) i deres kode.

Lad os grave dybere ned i, hvad denne rene arkitektur handler om. 

Nå, I har måske alle brugt eller i det mindste hørt om MVC-arkitektur. MVC står for Model, View, Controller. Tanken bag dette er at opdele vores projektstruktur i 3 forskellige sektioner.

1. Model: Den vil indeholde objektfilen, som afbildes med Relation/Documents i DB.

2. Styring: Det er anmodningshandleren og er ansvarlig for implementeringen af ​​forretningslogikken og al datamanipulation.

3. Vis: Denne del vil indeholde filer, der vedrører visning af data, enten HTML-filer eller nogle skabelonmotorfiler.

For at skabe en model har vi brug for en form for ORM/ODM værktøj/modul/bibliotek at bygge den med. For eksempel, hvis du direkte bruger modulet, lad os sige 'sequelize' og derefter bruge det samme til at implementere login i din controller og gøre din kerneforretningslogik afhængig af 'sequelize'. Lad os nu sige efter 10 år, at der er et bedre værktøj på markedet, som du vil bruge, men så snart du erstatter efterfølgeren med det, bliver du nødt til at ændre en masse linjer kode for at forhindre det i at går i stykker. Du bliver også nødt til at teste alle funktionerne igen for at kontrollere, om de er implementeret med succes eller ej, hvilket også kan spilde værdifuld tid og ressourcer. For at overvinde denne udfordring kan vi bruge det sidste princip i SOLID, som er afhængighedsinversionsprincippet, og en teknik kaldet afhængighedsinjektion for at undgå sådan noget rod.

Stadig forvirret? Lad mig forklare i detaljer.

Så hvad afhængighedsinversionsprincippet siger med enkle ord er, at du opretter din kerneforretningslogik og bygger derefter afhængighed omkring den. Med andre ord, frigør din kernelogik og forretningsregler fra enhver form for afhængighed og modificer de ydre lag på en sådan måde, at de er afhængige af din kernelogik i stedet for din logik afhængig af dette. Det er, hvad ren arkitektur er. Det fjerner afhængigheden fra din kerneforretningslogik og bygger systemet op omkring det på en sådan måde, at de ser ud til at være afhængige af det i stedet for at være afhængige af dem.

Lad os prøve at forstå dette med nedenstående diagram.

Kilde: Ren arkitekturkegle 

Du kan se, at vi har opdelt vores arkitektur i 4 lag:

1. Enheder: I sin kerne er enheder modellerne (Enterprise-regler), der definerer dine virksomhedsregler og fortæller, hvad applikationen handler om. Dette lag vil næppe ændre sig over tid og er normalt abstrakt og ikke tilgængeligt direkte. For eksempel har hver applikation en 'bruger'. Hvilke alle felter brugeren skal gemme, deres typer og relationer til andre entiteter vil omfatte en Entitet.

2. Brugstilfælde: Det fortæller os, hvordan vi kan implementere virksomhedsreglerne. Lad os tage eksemplet med brugeren igen. Nu ved vi hvilke data der skal betjenes, use casen fortæller os hvordan vi skal operere på disse data, ligesom brugeren vil have en adgangskode der skal krypteres, brugeren skal oprettes og passwordet kan ændres til enhver tid givet tidspunkt osv.

3. Controllere/gateways: Det er kanaler, der hjælper os med at implementere use cases ved hjælp af eksterne værktøjer og biblioteker ved hjælp af afhængighedsinjektion.

4. Eksterne værktøjer: Alle de værktøjer og biblioteker, vi bruger til at bygge vores logik, kommer under dette lag, f.eks. ORM, Emailer, Kryptering osv.

De værktøjer, vi bruger, afhænger af, hvordan vi kanaliserer dem til brugscases, og til gengæld vil use cases afhænge af de enheder, som er kernen i vores forretning. På denne måde har vi vendt afhængigheden fra udad til indad. Det er, hvad afhængighedsinversionsprincippet for SOLID indebærer.

Okay, nu har du fået essensen af ​​Nest.JS og forstået, hvordan ren arkitektur fungerer. Nu opstår spørgsmålet, hvordan disse to hænger sammen?  

Lad os prøve at forstå, hvad de 3 byggesten i Nest.JS er, og hvad hver af dem gør.

1. moduler: Nest.JS er opbygget på en sådan måde, at vi kan behandle hver funktion som et modul. For eksempel kan alt, der er forbundet med brugeren, såsom modeller, controllere, DTO'er, interfaces osv., adskilles som et modul. Et modul har en controller og en masse udbydere, som er injicerbare funktionaliteter som tjenester, orm, emailer osv.

2. controllere: Controllere i Nest.JS er grænseflader mellem netværket og din logik. De bruges til at håndtere anmodninger og returnere svar til klientsiden af ​​applikationen (for eksempel opkald til API'en).

3. Udbydere (tjenester): Udbydere er injicerbare tjenester/funktionaliteter, som vi kan injicere i controllere og andre udbydere for at give fleksibilitet og ekstra funktionalitet. De abstraherer enhver form for kompleksitet og logik.

At opsummere,

• Vi har controllere, der fungerer som grænseflader (3. lag af ren arkitektur)
• Vi har udbydere, som kan injiceres for at levere funktionalitet (4. lag af ren arkitektur: DB, enheder osv.)
• Vi kan også oprette tjenester og arkiver til at definere vores use case (2nd Layer)
• Vi kan definere vores enheder ved hjælp af DB-udbydere (1st Layer)

konklusion:

Nest.JS er et kraftfuldt Node.JS-framework og det mest kendte maskinskrift, der er tilgængeligt i dag. Nu hvor du har fået det laveste om dette rammeværk, må du spekulere på, om vi kan bruge det til at bygge en projektstruktur med en ren arkitektur. Nå, svaret er -Ja! Absolut. Hvordan? Jeg vil forklare i den næste serie af denne artikel. 

Indtil da, følg med!

Om forfatteren:

Junaid Bhat arbejder i øjeblikket som Tech Lead i Mantra Labs. Han er en teknologientusiast, der stræber efter at blive en bedre ingeniør hver dag ved at følge industristandarder og tilpasse sig en mere struktureret tilgang til problemløsning. 

Læs vores seneste blog: Golang-Beego Framework og dets applikationer

Viden der er værd at få leveret i din indbakke