Implementieren einer sauberen Architektur mit Nest.JS

Dieser Artikel richtet sich an Enthusiasten, die danach streben, sauberen, skalierbaren und vor allem umgestaltbaren Code zu schreiben. Es wird eine Vorstellung davon vermitteln, wie Nest.JS uns beim Schreiben von sauberem Code helfen kann und welche zugrunde liegende Architektur verwendet wird.

Um eine saubere Architektur mit Nest.JS zu implementieren, müssen wir zunächst verstehen, was dieses Framework ist und wie es funktioniert.

Nest oder Nest.JS ist ein Framework zum Erstellen effizienter, skalierbarer Node.js-Anwendungen (serverseitig), die mit TypeScript erstellt wurden. Es verwendet Express oder Fastify und ermöglicht eine Abstraktionsebene, die es Entwicklern ermöglicht, eine große Anzahl von Modulen (Drittanbieter) in ihrem Code zu verwenden.

Lassen Sie uns genauer untersuchen, worum es bei dieser sauberen Architektur geht. 

Nun, Sie alle haben vielleicht die MVC-Architektur verwendet oder zumindest davon gehört. MVC steht für Model, View, Controller. Die Idee dahinter ist, unsere Projektstruktur in 3 verschiedene Abschnitte zu unterteilen.

1. Modell: Es enthält die Objektdatei, die Relationen/Dokumenten in der DB zugeordnet ist.

2. Verantwortlicher: Es ist der Request-Handler und verantwortlich für die Implementierung der Geschäftslogik und die gesamte Datenbearbeitung.

3. Ansicht: Dieser Teil enthält Dateien, die sich mit der Anzeige der Daten befassen, entweder HTML-Dateien oder einige Templating-Engine-Dateien.

Um ein Modell zu erstellen, benötigen wir eine Art ORM/ODM-Tool/Modul/Bibliothek, um es zu erstellen. Wenn Sie beispielsweise das Modul direkt verwenden, sagen wir „sequelize“, und verwenden Sie es dann, um die Anmeldung in Ihrem Controller zu implementieren und Ihre Kerngeschäftslogik von „sequelize“ abhängig zu machen. Nun, auf der ganzen Linie, sagen wir nach 10 Jahren, gibt es ein besseres Tool auf dem Markt, das Sie verwenden möchten, aber sobald Sie sequelize damit ersetzen, müssen Sie viele Codezeilen ändern, um dies zu verhindern brechen. Außerdem müssen Sie alle Funktionen erneut testen, um zu überprüfen, ob sie erfolgreich bereitgestellt wurden oder nicht, was ebenfalls wertvolle Zeit und Ressourcen verschwenden kann. Um diese Herausforderung zu bewältigen, können wir das letzte Prinzip von SOLID, das Prinzip der Abhängigkeitsinversion, und eine Technik namens Abhängigkeitsinjektion verwenden, um ein solches Durcheinander zu vermeiden.

Immer noch verwirrt? Lassen Sie mich im Detail erklären.

Das Prinzip der Abhängigkeitsinversion sagt also in einfachen Worten, Sie erstellen Ihre Kerngeschäftslogik und bauen dann Abhängigkeiten um sie herum auf. Mit anderen Worten, befreien Sie Ihre Kernlogik und Ihre Geschäftsregeln von jeglicher Art von Abhängigkeit und modifizieren Sie die äußeren Schichten so, dass sie von Ihrer Kernlogik abhängig sind, anstatt dass Ihre Logik davon abhängig ist. Das ist saubere Architektur. Es entfernt die Abhängigkeit von Ihrer Kerngeschäftslogik und baut das System so um sie herum auf, dass sie eher davon abhängig zu sein scheinen, als dass es von ihnen abhängig ist.

Lassen Sie uns versuchen, dies anhand des folgenden Diagramms zu verstehen.

Quelle: Sauberer Architekturkegel 

Sie können sehen, dass wir unsere Architektur in 4 Schichten unterteilt haben:

1. Unternehmen: Im Kern sind Entitäten die Modelle (Unternehmensregeln), die Ihre Unternehmensregeln definieren und angeben, worum es in der Anwendung geht. Diese Schicht wird sich im Laufe der Zeit kaum ändern und ist normalerweise abstrakt und nicht direkt zugänglich. Beispielsweise hat jede Anwendung einen 'Benutzer'. Alle Felder, die der Benutzer speichern sollte, ihre Typen und Beziehungen zu anderen Entitäten bilden eine Entität.

2. Anwendungsfälle: Es sagt uns, wie wir die Unternehmensregeln implementieren können. Nehmen wir wieder das Beispiel des Benutzers. Jetzt wissen wir, mit welchen Daten gearbeitet werden soll, der Anwendungsfall sagt uns, wie wir mit diesen Daten arbeiten sollen, wie z. B. dass der Benutzer ein Passwort hat, das verschlüsselt werden muss, der Benutzer erstellt werden muss und das Passwort jederzeit geändert werden kann angegebener Zeitpunkt usw.

3. Controller/Gateways: Dies sind Kanäle, die uns helfen, die Anwendungsfälle mithilfe externer Tools und Bibliotheken mithilfe von Dependency Injection zu implementieren.

4. Externe Tools: Alle Tools und Bibliotheken, die wir zum Erstellen unserer Logik verwenden, werden unter diese Ebene fallen, z. ORM, E-Mailer, Verschlüsselung usw.

Die von uns verwendeten Tools hängen davon ab, wie wir sie in Anwendungsfälle kanalisieren, und die Anwendungsfälle wiederum hängen von den Einheiten ab, die den Kern unseres Geschäfts ausmachen. Auf diese Weise haben wir die Abhängigkeit von außen nach innen umgekehrt. Das impliziert das Prinzip der Abhängigkeitsinversion von SOLID.

Okay, jetzt haben Sie das Wesentliche von Nest.JS verstanden und verstanden, wie saubere Architektur funktioniert. Nun stellt sich die Frage, wie diese beiden zusammenhängen?  

Versuchen wir zu verstehen, was die 3 Bausteine ​​von Nest.JS sind und was jeder von ihnen tut.

1. Module: Nest.JS ist so strukturiert, dass wir jedes Feature als Modul behandeln können. Beispielsweise kann alles, was mit dem Benutzer verknüpft ist, wie Modelle, Controller, DTOs, Schnittstellen usw., als Modul getrennt werden. Ein Modul hat einen Controller und eine Reihe von Anbietern, die injizierbare Funktionalitäten wie Dienste, Orm, E-Mailer usw. sind.

2. Controller: Controller in Nest.JS sind Schnittstellen zwischen dem Netzwerk und Ihrer Logik. Sie werden verwendet, um Anforderungen zu verarbeiten und Antworten an die Clientseite der Anwendung zurückzugeben (z. B. Aufruf an die API).

3. Anbieter (Dienste): Anbieter sind injizierbare Dienste/Funktionalitäten, die wir in Controller und andere Anbieter einfügen können, um Flexibilität und zusätzliche Funktionalität bereitzustellen. Sie abstrahieren jede Form von Komplexität und Logik.

Zusammenfassen,

• Wir haben Controller, die als Schnittstellen fungieren (3. Schicht einer sauberen Architektur)
• Wir haben Anbieter, die eingefügt werden können, um Funktionalität bereitzustellen (4. Ebene einer sauberen Architektur: DB, Geräte usw.)
• Wir können auch Dienste und Repositories erstellen, um unseren Anwendungsfall zu definieren (2. Schicht).
• Wir können unsere Entitäten mithilfe von DB-Anbietern (1. Schicht) definieren.

Fazit:

Nest.JS ist ein leistungsstarkes Node.JS-Framework und das bekannteste heute verfügbare Typoskript. Jetzt, da Sie sich mit diesem Framework vertraut gemacht haben, fragen Sie sich sicherlich, ob wir es verwenden können, um eine Projektstruktur mit einer sauberen Architektur aufzubauen. Nun, die Antwort lautet: Ja! Unbedingt. Wie? Ich werde in der nächsten Serie dieses Artikels erklären. 

Bis dahin, bleibt dran!

Über den Autor:

Junaid Bhat arbeitet derzeit als Tech Lead in Mantra Labs. Er ist ein Technik-Enthusiast, der jeden Tag danach strebt, ein besserer Ingenieur zu werden, indem er Industriestandards befolgt und sich an einem strukturierteren Ansatz zur Problemlösung orientiert. 

Lesen Sie unseren neusten Blog: Golang-Beego Framework und seine Anwendungen

Wissen, das es wert ist, in Ihrem Posteingang geliefert zu werden