Implémentation d'une architecture propre avec Nest.JS

Cet article est destiné aux passionnés qui s'efforcent d'écrire du code propre, évolutif et, surtout, refactorisable. Cela donnera une idée de la manière dont Nest.JS peut nous aider à écrire du code propre et de l'architecture sous-jacente qu'il utilise.

La mise en œuvre d'une architecture propre avec Nest.JS nous obligera d'abord à comprendre ce qu'est ce framework et comment il fonctionne.

Nest ou Nest.JS est un framework permettant de créer des applications Node.js efficaces et évolutives (côté serveur) construites avec TypeScript. Il utilise Express ou Fastify et permet un niveau d'abstraction permettant aux développeurs d'utiliser une grande quantité de modules (tiers) dans leur code.

Approfondissons en quoi consiste cette architecture propre. 

Eh bien, vous avez peut-être tous utilisé ou au moins entendu parler de l'architecture MVC. MVC signifie Modèle, Vue, Contrôleur. L'idée derrière cela est de séparer notre structure de projet en 3 sections différentes.

1. Modèle: Il contiendra le fichier objet qui correspond aux relations/documents dans la base de données.

2. Contrôleur: C'est le gestionnaire de requêtes et il est responsable de la mise en œuvre de la logique métier et de toutes les manipulations de données.

3. Afficher : Cette partie contiendra des fichiers concernant l'affichage des données, soit des fichiers HTML, soit des fichiers de moteur de template.

Pour créer un modèle, nous avons besoin d'une sorte d'outil/module/bibliothèque ORM/ODM pour le construire. Par exemple, si vous utilisez directement le module, disons "sequelize", puis utilisez-le pour implémenter la connexion dans votre contrôleur et rendre votre logique métier principale dépendante de "sequelize". Maintenant, sur toute la ligne, disons qu'après 10 ans, il existe un meilleur outil sur le marché que vous souhaitez utiliser, mais dès que vous remplacez sequelize par celui-ci, vous devrez modifier de nombreuses lignes de code pour l'empêcher de rupture. En outre, vous devrez tester à nouveau toutes les fonctionnalités pour vérifier si elles sont déployées avec succès ou non, ce qui peut également faire perdre un temps et des ressources précieux. Pour surmonter ce défi, nous pouvons utiliser le dernier principe de SOLID qui est le principe d'inversion de dépendance, et une technique appelée injection de dépendance pour éviter un tel gâchis.

Encore confus? Laissez-moi vous expliquer en détail.

Donc, ce que le principe d'inversion de dépendance dit en termes simples, c'est que vous créez votre logique métier de base, puis créez une dépendance autour d'elle. En d'autres termes, libérez votre logique de base et vos règles métier de tout type de dépendance et modifiez les couches externes de manière à ce qu'elles dépendent de votre logique de base au lieu que votre logique en dépende. C'est ce qu'est une architecture propre. Il supprime la dépendance de votre logique métier principale et construit le système autour d'elle de telle manière qu'ils semblent en dépendre plutôt que d'en dépendre.

Essayons de comprendre cela avec le schéma ci-dessous.

La source: Cône d'architecture propre 

Vous pouvez voir que nous avons divisé notre architecture en 4 couches :

1. Entités : À la base, les entités sont les modèles (règles d'entreprise) qui définissent vos règles d'entreprise et indiquent en quoi consiste l'application. Cette couche ne changera guère au fil du temps et est généralement abstraite et non accessible directement. Par exemple, chaque application a un 'utilisateur'. Tous les champs que l'utilisateur doit stocker, leurs types et leurs relations avec d'autres entités constitueront une entité.

2. Cas d'utilisation : Il nous indique comment mettre en œuvre les règles d'entreprise. Reprenons l'exemple de l'utilisateur. Maintenant que nous savons sur quelles données opérer, le cas d'utilisation nous indique comment opérer sur ces données, comme l'utilisateur aura un mot de passe qui doit être crypté, l'utilisateur doit être créé et le mot de passe peut être changé à tout moment. moment donné, etc.

3. Contrôleurs/Passerelles : Ce sont des canaux qui nous aident à mettre en œuvre les cas d'utilisation à l'aide d'outils externes et de bibliothèques utilisant l'injection de dépendances.

4. Outils externes : Tous les outils et bibliothèques que nous utilisons pour construire notre logique relèveront de cette couche, par exemple. ORM, Emailer, Chiffrement, etc.

Les outils que nous utiliserons dépendront de la manière dont nous les canaliserons vers les cas d'utilisation et, à leur tour, les cas d'utilisation dépendront des entités qui constituent le cœur de notre activité. De cette façon, nous avons inversé la dépendance de l'extérieur vers l'intérieur. C'est ce qu'implique le principe d'inversion de dépendance de SOLID.

D'accord, vous avez maintenant compris l'essentiel de Nest.JS et compris le fonctionnement d'une architecture propre. Maintenant, la question se pose, comment ces deux sont liés?  

Essayons de comprendre quels sont les 3 blocs de construction de Nest.JS et ce que chacun d'eux fait.

1. Modules: Nest.JS est structuré de telle manière que nous pouvons traiter chaque fonctionnalité comme un module. Par exemple, tout ce qui est lié à l'utilisateur, comme les modèles, les contrôleurs, les DTO, les interfaces, etc., peut être séparé en un module. Un module a un contrôleur et un tas de fournisseurs qui sont des fonctionnalités injectables comme les services, orm, emailer, etc.

2. Contrôleurs: Les contrôleurs dans Nest.JS sont des interfaces entre le réseau et votre logique. Ils sont utilisés pour gérer les requêtes et renvoyer les réponses au côté client de l'application (par exemple, appel à l'API).

3. Prestataires (Services) : Les fournisseurs sont des services/fonctionnalités injectables que nous pouvons injecter dans les contrôleurs et autres fournisseurs pour offrir une flexibilité et des fonctionnalités supplémentaires. Ils font abstraction de toute forme de complexité et de logique.

Résumer,

• Nous avons des contrôleurs qui agissent comme des interfaces (3ème couche d'architecture propre)
• Nous avons des fournisseurs qui peuvent être injectés pour fournir des fonctionnalités (4ème couche d'architecture propre : DB, Devices, etc.)
• Nous pouvons également créer des services et des référentiels pour définir notre cas d'utilisation (2ème couche)
• Nous pouvons définir nos entités à l'aide de fournisseurs de bases de données (1ère couche)

Conclusion:

Nest.JS est un framework Node.JS puissant et le script dactylographié le plus connu disponible aujourd'hui. Maintenant que vous connaissez ce framework, vous devez vous demander si nous pouvons l'utiliser pour construire une structure de projet avec une architecture propre. Eh bien, la réponse est -Oui! Absolument. Comment? J'expliquerai dans la prochaine série de cet article. 

Jusque-là, restez à l'écoute !

About the Author:

Junaid Bhat travaille actuellement en tant que responsable technique chez Mantra Labs. C'est un passionné de technologie qui s'efforce de devenir chaque jour un meilleur ingénieur en suivant les normes de l'industrie et en s'alignant sur une approche plus structurée de la résolution de problèmes. 

Lisez notre dernier blog : Cadre Golang-Beego et ses applications

Des connaissances qui valent la peine d'être livrées dans votre boîte de réception