Tiszta architektúra megvalósítása a Nest.JS segítségével

Ez a cikk azoknak a rajongóknak szól, akik törekednek tiszta, méretezhető, és ami még fontosabb, újragyártható kód írására. Elképzelést ad arról, hogy a Nest.JS hogyan segíthet nekünk tiszta kód írásában, és milyen mögöttes architektúrát használ.

A tiszta architektúra Nest.JS segítségével való megvalósításához először meg kell értenünk, mi ez a keretrendszer, és hogyan működik.

A Nest vagy a Nest.JS egy olyan keretrendszer, amely hatékony, méretezhető Node.js-alkalmazásokat (szerveroldali) épít, TypeScripttel. Expresszt vagy Fastifyt használ, és olyan szintű absztrakciót tesz lehetővé, hogy a fejlesztők bőséges mennyiségű (harmadik féltől származó) modult használjanak a kódjukban.

Nézzük meg mélyebben, miről is szól ez a tiszta architektúra. 

Nos, mindannyian használta vagy legalább hallotta az MVC architektúrát. Az MVC a Model, View, Controller rövidítése. A mögöttes ötlet az, hogy projektstruktúránkat 3 különböző részre osztjuk.

1. Modell: Tartalmazza az objektumfájlt, amely a DB relációjával/dokumentumokkal van leképezve.

2. Vezérlő: Ő a kéréskezelő, és felelős az üzleti logika megvalósításáért és minden adatkezelésért.

3. Megtekintés: Ez a rész olyan fájlokat tartalmaz, amelyek az adatok megjelenítésével foglalkoznak, akár HTML-fájlokat, akár néhány sablon-motorfájlt.

Egy modell létrehozásához szükségünk van valamiféle ORM/ODM eszközre/modulra/könyvtárra, amellyel megépíthetjük. Például, ha közvetlenül használja a modult, mondjuk a „sequelize”-t, majd ezt használja a bejelentkezés megvalósításához a vezérlőben, és az alapvető üzleti logikát a „sequelize”-től függővé teszi. Most, mondjuk 10 év elteltével, van egy jobb eszköz a piacon, amelyet használni szeretne, de amint lecseréli a Sequelize-t, sok kódsort kell módosítania, hogy megakadályozza törés. Ezenkívül az összes funkciót még egyszer tesztelnie kell, hogy ellenőrizze, sikeresen telepítette-e vagy sem, ami szintén értékes időt és erőforrásokat pazarolhat. Ennek a kihívásnak a leküzdésére használhatjuk a SOLID utolsó elvét, amely a Dependency Inversion Principle, és a függőségi injekciónak nevezett technikát, hogy elkerüljük az ilyen zűrzavart.

Még mindig zavart? Hadd magyarázzam el részletesen.

Tehát a Dependency Inversion Principle egyszerű szavakkal azt mondja, hogy létrehozza az alapvető üzleti logikát, majd függőséget épít rá. Más szóval, szabadítsd fel az alapvető logikát és üzleti szabályaidat mindenféle függőségtől, és módosítsd a külső rétegeket úgy, hogy azok az Ön alapvető logikájától függjenek, ahelyett, hogy ettől függnének. Ez a tiszta építészet. Kivonja a függőséget az alapvető üzleti logikából, és úgy építi fel köré a rendszert, hogy úgy tűnik, hogy ők függenek tőle, nem pedig tőlük.

Próbáljuk megérteni ezt az alábbi ábrával.

Forrás: Clean Architecture Cone 

Láthatja, hogy az architektúránkat 4 rétegre osztottuk:

1. Entitások: Lényegében az entitások a modellek (Vállalati szabályok), amelyek meghatározzák a vállalati szabályokat, és elmondják, miről szól az alkalmazás. Ez a réteg alig változik az idő múlásával, és általában absztrakt, és nem érhető el közvetlenül. Például minden alkalmazásnak van "felhasználója". A felhasználó által tárolt összes mező, azok típusai és kapcsolatai más entitásokkal alkotnak majd egy entitást.

2. Használati esetek: Megmondja, hogyan tudjuk végrehajtani a vállalati szabályokat. Vegyük ismét a felhasználó példáját. Most már tudjuk, milyen adatokat kell kezelni, a használati eset megmondja, hogyan kell kezelni ezeket az adatokat, például a felhasználónak lesz egy jelszava, amelyet titkosítani kell, létre kell hozni a felhasználót, és a jelszó bármikor megváltoztatható adott időpont stb.

3. Vezérlők/átjárók: Ezek olyan csatornák, amelyek segítenek a használati esetek megvalósításában külső eszközök és függvénytárak segítségével, függőségi injekció segítségével.

4. Külső eszközök: Az összes eszköz és könyvtár, amelyet a logikánk felépítéséhez használunk, ebbe a rétegbe kerül, pl. ORM, e-mail küldő, titkosítás stb.

Az általunk használt eszközök attól függnek, hogy hogyan irányítjuk őket használati esetekre, a használati esetek pedig az üzleti tevékenységünk magját képező entitásoktól függenek. Így a függőséget kifelé fordítottuk befelé. Erre utal a SOLID függőségi inverziós alapelve.

Oké, mostanra megértette a Nest.JS lényegét, és megértette, hogyan működik a tiszta architektúra. Felmerül a kérdés, hogyan függ össze ez a kettő?  

Próbáljuk megérteni, mi a Nest.JS 3 építőköve, és mindegyik mit csinál.

1. modulok: A Nest.JS olyan felépítésű, hogy minden funkciót modulként kezelhetünk. Pl. minden, ami a Felhasználóhoz kapcsolódik, mint például modellek, vezérlők, DTO-k, interfészek stb., modulként elkülöníthető. A modulnak van egy vezérlője és egy csomó szolgáltatója, amelyek beinjektálható funkciókat, például szolgáltatásokat, orm-ot, email-t stb.

2. vezérlők: A Nest.JS vezérlői interfészek a hálózat és a logika között. Ezek a kérések kezelésére szolgálnak, és válaszokat küldenek vissza az alkalmazás ügyféloldalára (például az API hívása).

3. Szolgáltatók (szolgáltatások): A szolgáltatók olyan befecskendezhető szolgáltatások/funkciók, amelyeket a vezérlőkbe és más szolgáltatókba illeszthetünk a rugalmasság és az extra funkcionalitás biztosítása érdekében. Elvonják a komplexitás és a logika bármely formáját.

Összefoglalni,

• Vannak vezérlőink, amelyek interfészként működnek (a tiszta architektúra harmadik rétege)
• Vannak olyan szolgáltatóink, amelyekbe bele lehet adni a funkcionalitást (a tiszta architektúra 4. rétege: DB, Eszközök stb.)
• Szolgáltatásainkat és adattárakat is létrehozhatunk a használati esetünk meghatározásához (2. réteg)
• Az entitásainkat DB szolgáltatók segítségével határozhatjuk meg (1. réteg)

Következtetés:

A Nest.JS egy erőteljes Node.JS keretrendszer és a ma elérhető legismertebb gépirat. Most, hogy megvan ennek a keretrendszernek a mélypontja, biztos azon tűnődhet, hogy felhasználhatjuk-e egy tiszta architektúrájú projektstruktúra felépítésére. Nos, a válasz: Igen! Teljesen. Hogyan? A cikk következő sorozatában elmagyarázom. 

Addig is maradj velünk!

A szerzőről:

Junaid Bhat jelenleg a Mantra Labs műszaki vezetőjeként dolgozik. Technológiai rajongó, aki nap mint nap jobb mérnökké kíván válni az iparági szabványok követésével és a problémamegoldás strukturáltabb megközelítésével. 

Olvassa el legújabb blogunkat: Golang-Beego Framework és alkalmazásai

A tudást érdemes a postaládájába juttatni