Wdrażanie czystej architektury z Nest.JS

Ten artykuł jest przeznaczony dla entuzjastów, którzy dążą do pisania czystego, skalowalnego i co ważniejsze, refaktoryzowanego kodu. Da to wyobrażenie o tym, w jaki sposób Nest.JS może pomóc nam napisać czysty kod i jakiej architektury bazowej używa.

Wdrożenie czystej architektury za pomocą Nest.JS będzie wymagało od nas najpierw zrozumienia, czym jest ten framework i jak działa.

Nest lub Nest.JS to platforma do tworzenia wydajnych, skalowalnych aplikacji Node.js (po stronie serwera) zbudowanych za pomocą TypeScript. Używa Express lub Fastify i pozwala na pewien poziom abstrakcji, aby umożliwić programistom korzystanie z dużej liczby modułów (stron trzecich) w ich kodzie.

Przyjrzyjmy się głębiej, o co chodzi w tej czystej architekturze. 

Cóż, wszyscy mogliście używać lub przynajmniej słyszeć o architekturze MVC. MVC oznacza model, widok, kontroler. Ideą tego jest podzielenie naszej struktury projektu na 3 różne sekcje.

1. Model: Będzie zawierał plik Object, który mapuje relację/dokumenty w DB.

2. Kontroler: Jest to obsługa żądań i jest odpowiedzialna za implementację logiki biznesowej oraz całą manipulację danymi.

3. Zobacz: Ta część będzie zawierać pliki związane z wyświetlaniem danych, albo pliki HTML, albo niektóre pliki silnika szablonów.

Aby stworzyć model, potrzebujemy jakiegoś narzędzia/modułu/biblioteki ORM/ODM, aby go zbudować. Na przykład, jeśli bezpośrednio używasz modułu, powiedzmy „sequelize”, a następnie użyj tego samego, aby zaimplementować logowanie w kontrolerze i uzależnić podstawową logikę biznesową od „sequelize”. Teraz, powiedzmy po 10 latach, jest na rynku lepsze narzędzie, z którego chcesz korzystać, ale jak tylko zastąpisz nim sequelizę, będziesz musiał zmienić wiele wierszy kodu, aby temu zapobiec łamanie. Ponadto będziesz musiał ponownie przetestować wszystkie funkcje, aby sprawdzić, czy zostało wdrożone pomyślnie, czy nie, co może również marnować cenny czas i zasoby. Aby przezwyciężyć to wyzwanie, możemy wykorzystać ostatnią zasadę SOLID, czyli Zasadę Inwersji Zależności, oraz technikę zwaną wstrzykiwaniem zależności, aby uniknąć takiego bałaganu.

Nadal zdezorientowany? Pozwólcie, że wyjaśnię szczegółowo.

Tak więc zasada odwrócenia zależności mówi prostymi słowami, że tworzysz swoją podstawową logikę biznesową, a następnie budujesz wokół niej zależność. Innymi słowy, uwolnij swoją podstawową logikę i reguły biznesowe od wszelkiego rodzaju zależności i zmodyfikuj zewnętrzne warstwy w taki sposób, aby były zależne od podstawowej logiki, a nie od logiki zależnej od tego. Tym właśnie jest czysta architektura. Usuwa zależność z podstawowej logiki biznesowej i buduje wokół niej system w taki sposób, że wydają się być od niej zależne, a nie od nich zależne.

Spróbujmy to zrozumieć na poniższym schemacie.

Źródło: Stożek czystej architektury 

Widać, że podzieliliśmy naszą architekturę na 4 warstwy:

1. Podmioty: U podstaw encji są modele (reguły korporacyjne), które definiują reguły przedsiębiorstwa i mówią, o czym jest aplikacja. Ta warstwa prawie się nie zmieni w czasie i zwykle jest abstrakcyjna i niedostępna bezpośrednio. Np. każda aplikacja ma „użytkownika”. To, jakie wszystkie pola użytkownik powinien przechowywać, ich typy oraz relacje z innymi encjami będą stanowić Entity.

2. Przypadki użycia: Mówi nam, jak możemy wdrożyć reguły przedsiębiorstwa. Weźmy ponownie przykład użytkownika. Teraz wiemy, jakie dane mają być operowane, przypadek użycia mówi nam, jak operować na tych danych, na przykład użytkownik będzie miał hasło, które musi być zaszyfrowane, użytkownik musi zostać utworzony, a hasło można zmienić w dowolnym w danym momencie itp.

3. Kontrolery/bramy: Są to kanały, które pomagają nam wdrażać przypadki użycia za pomocą zewnętrznych narzędzi i bibliotek z wykorzystaniem wstrzykiwania zależności.

4. Narzędzia zewnętrzne: Wszystkie narzędzia i biblioteki, których używamy do budowania naszej logiki, znajdą się pod tą warstwą, np. ORM, Emailer, Szyfrowanie itp.

Używane przez nas narzędzia będą zależeć od tego, jak skierujemy je do przypadków użycia, a przypadki użycia będą zależeć od podmiotów, które są rdzeniem naszej działalności. W ten sposób odwróciliśmy zależność od zewnętrznej do wewnętrznej. To właśnie sugeruje Dependency Inversion Principal SOLID.

Okej, już znasz istotę Nest.JS i rozumiesz, jak działa czysta architektura. Teraz pojawia się pytanie, jak te dwa są powiązane?  

Spróbujmy zrozumieć, jakie są 3 bloki konstrukcyjne Nest.JS i co każdy z nich robi.

1. Moduły: Nest.JS jest skonstruowany w taki sposób, że każdą funkcję możemy traktować jako moduł. Np. wszystko, co jest powiązane z Użytkownikiem, takie jak modele, kontrolery, DTO, interfejsy itp., można wydzielić jako moduł. Moduł ma kontroler i grupę dostawców, które są funkcjonalnościami do wstrzykiwania, takimi jak usługi, orm, emailer itp.

2. Kontrolery: Kontrolery w Nest.JS to interfejsy między siecią a twoją logiką. Służą do obsługi żądań i zwracania odpowiedzi po stronie klienta aplikacji (na przykład wywołania API).

3. Dostawcy (Usługi): Dostawcy to usługi/funkcje, które można wstrzykiwać do kontrolerów i innych dostawców, aby zapewnić elastyczność i dodatkową funkcjonalność. Abstrahują każdą formę złożoności i logiki.

Podsumowując,

• Mamy kontrolery pełniące rolę interfejsów (trzecia warstwa czystej architektury)
• Mamy dostawców, których można wstrzyknąć, aby zapewnić funkcjonalność (4 warstwa czystej architektury: DB, Urządzenia itp.)
• Możemy również tworzyć usługi i repozytoria, aby zdefiniować nasz przypadek użycia (druga warstwa)
• Możemy zdefiniować nasze podmioty za pomocą dostawców DB (I Warstwa)

Wnioski:

Nest.JS to potężny framework Node.JS i najbardziej znany obecnie dostępny maszynopis. Teraz, gdy znasz już ten framework, musisz się zastanawiać, czy możemy go użyć do zbudowania struktury projektu z czystą architekturą. Cóż, odpowiedź brzmi -Tak! Absolutnie. Jak? Wyjaśnię to w następnej serii tego artykułu. 

Do tego czasu bądź na bieżąco!

O autorze:

Junaid Bhat pracuje obecnie jako kierownik techniczny w Mantra Labs. Jest entuzjastą technologii, który każdego dnia stara się zostać lepszym inżynierem, przestrzegając standardów branżowych i kierując się bardziej ustrukturyzowanym podejściem do rozwiązywania problemów. 

Przeczytaj nasz najnowszy blog: Golang-Beego Framework i jego aplikacje

Wiedza, którą warto dostarczyć w swojej skrzynce odbiorczej