Puhta arhitektuuri rakendamine Nest.JS-iga

See artikkel on mõeldud entusiastidele, kes püüavad kirjutada puhast, skaleeritavat ja, mis veelgi olulisem, taastatav koodi. See annab ülevaate sellest, kuidas Nest.JS saab aidata meil puhast koodi kirjutada ja millist alusarhitektuuri see kasutab.

Puhta arhitektuuri juurutamine Nest.JS-iga nõuab meilt esmalt aru, mis see raamistik on ja kuidas see töötab.

Nest või Nest.JS on raamistik tõhusate, skaleeritavate Node.js-rakenduste loomiseks (serveripoolne), mis on ehitatud koos TypeScriptiga. See kasutab teenust Express või Fastify ja võimaldab abstraktsioonitaset, mis võimaldab arendajatel kasutada oma koodis rohkelt (kolmanda osapoole) mooduleid.

Uurime sügavamalt, mida see puhas arhitektuur endast kujutab. 

Võib-olla olete kõik MVC arhitektuuri kasutanud või sellest vähemalt kuulnud. MVC tähistab mudelit, vaadet, kontrollerit. Selle idee on jagada meie projekti struktuur kolmeks erinevaks osaks.

1. Mudel: See sisaldab objektifaili, mis on andmebaasis seotud seoste/dokumentidega.

2. Kontroller: See on päringu töötleja ja vastutab äriloogika rakendamise ja kogu andmetega manipuleerimise eest.

3. Vaata: See osa sisaldab faile, mis on seotud andmete kuvamisega, kas HTML-failid või mõned mallimootori failid.

Mudeli loomiseks vajame selle koostamiseks mingit ORM-i/ODM-i tööriista/moodulit/teeki. Näiteks kui kasutate moodulit otse, oletame, et "järgimine" ja seejärel kasutage sama oma kontrollerisse sisselogimise juurutamiseks ja oma põhitegevuse loogika muutmiseks "järjestusest" sõltuvaks. Nüüd, oletame, et 10 aasta pärast on turul parem tööriist, mida soovite kasutada, kuid niipea, kui asendate sellega järjestuse, peate muutma palju koodiridu, et seda vältida. purustamine. Samuti peate uuesti testima kõiki funktsioone, et kontrollida, kas see on edukalt juurutatud või mitte, mis võib raisata ka väärtuslikku aega ja ressursse. Selle väljakutse ületamiseks saame kasutada SOLID-i viimast põhimõtet, mis on sõltuvuse ümberpööramise põhimõte, ja tehnikat, mida nimetatakse sõltuvuse süstimiseks, et sellist segadust vältida.

Kas olete endiselt segaduses? Las ma selgitan üksikasjalikult.

Sõltuvuste ümberpööramise põhimõte ütleb lihtsate sõnadega, et loote oma põhilise äriloogika ja seejärel loote selle ümber sõltuvuse. Teisisõnu vabastage oma põhiloogika ja ärireeglid igasugusest sõltuvusest ning muutke väliskihte nii, et need sõltuksid teie põhiloogikast, mitte sellest sõltuvast loogikast. See on puhas arhitektuur. See eemaldab sõltuvuse teie põhitegevuse loogikast ja loob süsteemi selle ümber nii, et nad näivad sellest sõltuvat, mitte ei sõltu neist.

Proovime seda mõista alloleva diagrammi abil.

Allikas: Clean Architecture Cone 

Näete, et oleme oma arhitektuuri jaganud neljaks kihiks:

1. Üksused: Olemite põhiolemus on mudelid (ettevõtte reeglid), mis määratlevad teie ettevõtte reeglid ja ütlevad, mida rakendus puudutab. See kiht aja jooksul peaaegu ei muutu ja on tavaliselt abstraktne ega ole otseselt juurdepääsetav. Näiteks igal rakendusel on "kasutaja". Kõik väljad, mida kasutaja peaks salvestama, nende tüübid ja suhted teiste olemitega, moodustavad olemi.

2. Kasutusjuhtumid: See ütleb meile, kuidas saame ettevõtte eeskirju rakendada. Võtame uuesti kasutaja näite. Nüüd teame, milliste andmetega opereerida, kasutusjuhtum ütleb meile, kuidas nende andmetega toimida, näiteks kasutajal on parool, mis tuleb krüpteerida, kasutaja tuleb luua ja parooli saab igal ajal muuta antud ajahetk jne.

3. Kontrollerid/lüüsid: Need on kanalid, mis aitavad meil kasutusjuhtumeid juurutada väliste tööriistade ja sõltuvussüsti abil teekide abil.

4. Välised tööriistad: Selle kihi alla kuuluvad kõik tööriistad ja teegid, mida me oma loogika koostamiseks kasutame, nt. ORM, meili saatja, krüpteerimine jne.

Tööriistad, mida me kasutame, sõltuvad sellest, kuidas me neid kasutusjuhtudele suuname, ja kasutusjuhtumid omakorda sõltuvad üksustest, mis on meie äritegevuse tuum. Nii oleme pööranud sõltuvuse väljastpoolt sissepoole. Seda tähendab SOLIDi sõltuvuse inversiooni printsiip.

Olgu, nüüdseks olete Nest.JS-i olemuse aru saanud ja aru saanud, kuidas puhas arhitektuur töötab. Nüüd tekib küsimus, kuidas need kaks omavahel seotud on?  

Proovime mõista, mis on Nest.JS-i kolm ehitusplokki ja mida igaüks neist teeb.

1. Moodulid: Nest.JS on üles ehitatud nii, et saame käsitleda iga funktsiooni moodulina. Näiteks võib kõik, mis on kasutajaga seotud, näiteks mudelid, kontrollerid, DTO-d, liidesed jne, eraldada moodulina. Moodulil on kontroller ja hulk pakkujaid, mis on süstitavad funktsioonid, nagu teenused, orm, meiler jne.

2. Kontrollerid: Nest.JS-i kontrollerid on võrgu ja teie loogika vahelised liidesed. Neid kasutatakse taotluste käsitlemiseks ja vastuste tagastamiseks rakenduse kliendipoolele (näiteks API-le helistamiseks).

3. Pakkujad (teenused): Pakkujad on süstitavad teenused/funktsioonid, mida saame sisestada kontrolleritesse ja muudesse pakkujatesse, et pakkuda paindlikkust ja lisafunktsioone. Nad abstraheerivad igasuguse keerukuse ja loogika.

Kokku võtma,

• Meil on kontrollerid, mis toimivad liidestena (puhta arhitektuuri kolmas kiht)
• Meil on teenusepakkujaid, keda saab funktsioonide pakkumiseks süstida (puhta arhitektuuri neljas kiht: DB, seadmed jne)
• Samuti saame luua teenuseid ja hoidlaid, et määratleda meie kasutusjuht (2. kiht)
• Saame oma olemid määratleda DB pakkujate abil (1. kiht)

Järeldus:

Nest.JS on võimas Node.JS raamistik ja tänapäeval kõige tuntum masinakiri. Nüüd, kui teil on selle raamistiku madalseisu, peate kindlasti mõtlema, kas saame seda kasutada puhta arhitektuuriga projektistruktuuri ehitamiseks. Noh, vastus on - jah! Absoluutselt. Kuidas? Selgitan selle artikli järgmises seerias. 

Seni, püsige lainel!

Teave Autor:

Junaid Bhat töötab praegu Mantra Labsi tehnilise juhina. Ta on tehnikahuviline, kes püüab saada iga päev paremaks inseneriks, järgides tööstusharu standardeid ja järgides struktureeritumat lähenemisviisi probleemide lahendamisele. 

Loe meie viimast blogi: Golang-Beego raamistik ja selle rakendused

Teadmised, mis on väärt teie postkasti edastamist