Puhtaan arkkitehtuurin käyttöönotto Nest.JS:llä

Tämä artikkeli on tarkoitettu harrastajille, jotka pyrkivät kirjoittamaan puhdasta, skaalautuvaa ja mikä tärkeintä uudelleen muotoiltavaa koodia. Se antaa käsityksen siitä, kuinka Nest.JS voi auttaa meitä kirjoittamaan puhdasta koodia ja mitä taustalla olevaa arkkitehtuuria se käyttää.

Puhtaan arkkitehtuurin toteuttaminen Nest.JS:n avulla edellyttää, että meidän on ensin ymmärrettävä, mikä tämä kehys on ja miten se toimii.

Nest tai Nest.JS on kehys tehokkaiden, skaalautuvien Node.js-sovellusten rakentamiseen (palvelinpuolella), jotka on rakennettu TypeScriptillä. Se käyttää Express- tai Fastifyta ja mahdollistaa abstraktiotason, jotta kehittäjät voivat käyttää koodissaan runsaasti moduuleja (kolmannen osapuolen valmistamia).

Kaivataanpa syvemmälle, mistä tässä puhtaassa arkkitehtuurissa on kyse. 

No, olette kaikki ehkä käyttäneet tai ainakin kuulleet MVC-arkkitehtuurista. MVC tulee sanoista Model, View, Controller. Ajatuksena tässä on jakaa projektirakenne kolmeen eri osaan.

1. Malli: Se sisältää Object-tiedoston, joka yhdistää relaatio/asiakirjat tietokantaan.

2. Ohjain: Se on pyynnön käsittelijä ja vastaa liiketoimintalogiikan toteutuksesta ja kaikesta tietojen käsittelystä.

3. Näytä: Tämä osa sisältää tiedostoja, jotka liittyvät tietojen näyttämiseen, joko HTML-tiedostoja tai joitain mallipohjatiedostoja.

Mallin luomiseksi tarvitsemme jonkinlaisen ORM/ODM-työkalun/moduulin/kirjaston, jolla se rakennetaan. Jos esimerkiksi käytät moduulia suoraan, sanotaan "sequelize" ja käytä sitten samaa kirjautumisen toteuttamiseen ohjaimessasi ja tehdäksesi ydinliiketoimintalogiikkasi riippuvaiseksi "sequelize"-toiminnosta. Nyt, sanotaan 10 vuoden jälkeen, markkinoilla on parempi työkalu, jota haluat käyttää, mutta heti kun korvaat sequelisen sillä, sinun on vaihdettava useita koodirivejä estääksesi sen murtumassa. Sinun on myös testattava kaikkia ominaisuuksia vielä kerran tarkistaaksesi, onko se otettu käyttöön onnistuneesti vai ei, mikä voi myös tuhlata arvokasta aikaa ja resursseja. Tämän haasteen voittamiseksi voimme käyttää SOLIDin viimeistä periaatetta, joka on riippuvuuden inversioperiaate, ja riippuvuusinjektio-nimistä tekniikkaa tällaisen sotkun välttämiseksi.

Vieläkin hämmentynyt? Selitän yksityiskohtaisesti.

Riippuvuuden inversioperiaate sanoo yksinkertaisin sanoin, että luot ydinliiketoimintalogiikkasi ja rakennat sitten riippuvuuden sen ympärille. Toisin sanoen vapauta ydinlogiikkasi ja liiketoimintasääntösi kaikesta riippuvuudesta ja muokkaa ulompia kerroksia siten, että ne ovat riippuvaisia ​​ydinlogiikastasi tästä riippuvaisen logiikkasi sijaan. Sitä puhdas arkkitehtuuri on. Se poistaa riippuvuuden ydinliiketoiminnastasi ja rakentaa järjestelmän sen ympärille siten, että he näyttävät olevan riippuvaisia ​​siitä sen sijaan, että se olisi riippuvainen heistä.

Yritetään ymmärtää tämä alla olevan kaavion avulla.

Lähde: Clean Architecture Cone 

Voit nähdä, että olemme jakaneet arkkitehtuurimme 4 kerrokseen:

1. Entiteetit: Entiteetit ovat pohjimmiltaan malleja (yrityssäännöt), jotka määrittävät yrityksesi säännöt ja kertovat, mistä sovelluksessa on kyse. Tämä kerros tuskin muuttuu ajan myötä, ja se on yleensä abstrakti eikä siihen pääse suoraan käsiksi. Esimerkiksi jokaisella sovelluksella on "käyttäjä". Entiteetin muodostavat kaikki kentät, jotka käyttäjän tulee tallentaa, niiden tyypit ja suhteet muihin entiteeteihin.

2. Käyttötapaukset: Se kertoo meille, kuinka voimme toteuttaa yrityssäännöt. Otetaanpa taas esimerkki käyttäjästä. Nyt tiedämme, mitä tietoja tulee käsitellä, käyttötapaus kertoo, kuinka näitä tietoja käytetään, kuten käyttäjä saa salasanan, joka on salattava, käyttäjä on luotava ja salasana voidaan muuttaa milloin tahansa annettu aika jne.

3. Ohjaimet/yhdyskäytävät: Nämä ovat kanavia, jotka auttavat meitä toteuttamaan käyttötapauksia käyttämällä ulkoisia työkaluja ja kirjastoja riippuvuuslisäämällä.

4. Ulkoiset työkalut: Kaikki työkalut ja kirjastot, joita käytämme logiikkamme rakentamiseen, tulevat tämän kerroksen alle, esim. ORM, sähköposti, salaus jne.

Käyttämämme työkalut riippuvat siitä, kuinka kanavoimme ne käyttötapauksiin, ja käyttötapaukset puolestaan ​​riippuvat kokonaisuuksista, jotka ovat liiketoimintamme ydin. Tällä tavalla olemme kääntäneet riippuvuuden ulospäin sisäänpäin. Sitä SOLIDin riippuvuuden inversioperiaate tarkoittaa.

Okei, olet nyt ymmärtänyt Nest.JS:n ytimen ja ymmärtänyt, kuinka puhdas arkkitehtuuri toimii. Nyt herää kysymys, miten nämä kaksi liittyvät toisiinsa?  

Yritetään ymmärtää, mitkä ovat Nest.JS:n kolme rakennuspalikoita ja mitä kukin niistä tekee.

1. moduulit: Nest.JS on rakennettu siten, että voimme käsitellä jokaista ominaisuutta moduulina. Esimerkiksi kaikki, mikä on linkitetty käyttäjään, kuten mallit, ohjaimet, DTO:t, liitännät jne., voidaan erottaa moduuliksi. Moduulissa on ohjain ja joukko palveluntarjoajia, jotka ovat injektoitavia toimintoja, kuten palvelut, orm, emailer jne.

2. ohjaimet: Nest.JS:n ohjaimet ovat rajapintoja verkon ja logiikkasi välillä. Niitä käytetään pyyntöjen käsittelemiseen ja vastausten palauttamiseen sovelluksen asiakaspuolelle (esimerkiksi kutsu API:lle).

3. Palveluntarjoajat (palvelut): Palveluntarjoajat ovat injektoitavia palveluita/toimintoja, jotka voimme lisätä ohjaimiin ja muihin palveluntarjoajiin tarjotaksemme joustavuutta ja lisätoimintoja. Ne abstraktioivat kaikenlaista monimutkaisuutta ja logiikkaa.

Yhteenvetona

• Meillä on ohjaimia, jotka toimivat rajapinnoina (puhtaan arkkitehtuurin kolmas kerros)
• Meillä on palveluntarjoajia, jotka voidaan lisätä tarjoamaan toimintoja (puhtaan arkkitehtuurin neljäs kerros: DB, laitteet jne.)
• Voimme myös luoda palveluita ja tietovarastoja käyttötapamme määrittelemiseksi (2. kerros)
• Voimme määrittää entiteetit käyttämällä DB-palveluntarjoajia (1st Layer)

Johtopäätös:

Nest.JS on tehokas Node.JS-kehys ja tunnetuin saatavilla oleva konekirjoitus. Nyt kun sinulla on tämän kehyksen alaraja, mietit varmasti, voimmeko käyttää sitä rakentamaan projektirakenteen puhtaalla arkkitehtuurilla. No, vastaus on - Kyllä! Ehdottomasti. Miten? Selitän tämän artikkelin seuraavassa sarjassa. 

Siihen asti, pysy kuulolla!

Author:

Junaid Bhat työskentelee tällä hetkellä teknisenä johtajana Mantra Labsissa. Hän on tekniikan innokas, joka pyrkii tulemaan paremmaksi insinööriksi joka päivä noudattamalla alan standardeja ja suuntautumalla kohti järjestelmällisempää lähestymistapaa ongelmanratkaisuun. 

Lue uusin blogimme: Golang-Beego Framework ja sen sovellukset

Tieto, joka on syytä toimittaa postilaatikkoosi