Впровадження чистої архітектури за допомогою Nest.JS

Ця стаття призначена для ентузіастів, які прагнуть писати чистий, масштабований і, що важливіше, код, що піддається рефакторингу. Це дасть уявлення про те, як Nest.JS може допомогти нам написати чистий код і яку базову архітектуру він використовує.

Реалізація чистої архітектури з Nest.JS вимагатиме від нас спочатку зрозуміти, що це за фреймворк і як він працює.

Nest або Nest.JS — це структура для створення ефективних, масштабованих програм Node.js (на стороні сервера), створених за допомогою TypeScript. Він використовує Express або Fastify і забезпечує рівень абстракції, щоб розробники могли використовувати достатню кількість модулів (сторонніх) у своєму коді.

Давайте глибше розберемося, що таке чиста архітектура. 

Що ж, ви всі могли використовувати або принаймні чути про архітектуру MVC. MVC означає Model, View, Controller. Ідея цього полягає в тому, щоб розділити структуру нашого проекту на 3 різні розділи.

1. Модель: Він міститиме файл Object, який зіставляється з Relation/Documents у БД.

2. Контролер: Він є обробником запитів і відповідає за реалізацію бізнес-логіки та всі маніпуляції з даними.

3. Переглянути: Ця частина міститиме файли, пов’язані з відображенням даних, або файли HTML, або деякі файли механізму шаблонів.

Щоб створити модель, нам потрібен якийсь інструмент/модуль/бібліотека ORM/ODM для її створення. Наприклад, якщо ви безпосередньо використовуєте модуль, скажімо, «sequelize», а потім використовуєте його, щоб реалізувати вхід у свій контролер і зробити вашу основну бізнес-логіку залежною від «sequelize». Тепер, скажімо, через 10 років на ринку є кращий інструмент, який ви хочете використовувати, але щойно ви заміните на нього sequelize, вам доведеться змінити багато рядків коду, щоб запобігти цьому поломка. Крім того, вам доведеться ще раз перевірити всі функції, щоб перевірити, чи успішно їх розгорнуто чи ні, що також може втрачати дорогоцінний час і ресурси. Щоб подолати цю проблему, ми можемо використати останній принцип SOLID, який є принципом інверсії залежностей, і техніку під назвою ін’єкція залежностей, щоб уникнути такого безладу.

Все ще плутаєтеся? Дозвольте мені пояснити детально.

Отже, принцип інверсії залежностей говорить простими словами: ви створюєте свою основну бізнес-логіку, а потім будуєте залежність навколо неї. Іншими словами, звільніть свою основну логіку та бізнес-правила від будь-якої залежності та змініть зовнішні рівні таким чином, щоб вони залежали від вашої основної логіки, а не від неї. Ось що таке чиста архітектура. Він усуває залежність від вашої основної бізнес-логіки та будує навколо неї систему таким чином, щоб здавалося, що вони залежать від неї, а не вона залежить від них.

Давайте спробуємо зрозуміти це за допомогою діаграми нижче.

джерело: Конус чистої архітектури 

Ви бачите, що ми розділили нашу архітектуру на 4 рівні:

1. Суб'єкти: За своєю суттю сутності — це моделі (правила підприємства), які визначають корпоративні правила та вказують, про що йдеться у програмі. Цей шар майже не зміниться з часом і зазвичай є абстрактним і недоступним безпосередньо. Наприклад, кожна програма має «користувача». Усі поля, які повинен зберігати користувач, їх типи та зв’язки з іншими сутностями складатимуть Сутність.

2. Випадки використання: Це говорить нам, як ми можемо впроваджувати корпоративні правила. Знову візьмемо приклад користувача. Тепер ми знаємо, з якими даними потрібно працювати, варіант використання говорить нам, як працювати з цими даними, наприклад, користувач матиме пароль, який потрібно зашифрувати, користувача потрібно створити, і пароль можна змінити будь-коли заданий момент часу тощо.

3. Контролери/шлюзи: Це канали, які допомагають нам реалізовувати варіанти використання за допомогою зовнішніх інструментів і бібліотек із застосуванням ін’єкції залежностей.

4. Зовнішні інструменти: Усі інструменти та бібліотеки, які ми використовуємо для створення нашої логіки, потраплять під цей рівень, наприклад. ORM, Emailer, Encryption тощо.

Інструменти, які ми використовуємо, залежатимуть від того, як ми спрямовуємо їх на сценарії використання, і, у свою чергу, варіанти використання залежатимуть від організацій, які є основою нашого бізнесу. Таким чином ми перевернули залежність ззовні всередину. Це те, що передбачає принцип інверсії залежностей SOLID.

Гаразд, тепер ви зрозуміли суть Nest.JS і зрозуміли, як працює чиста архітектура. Тепер виникає питання, як ці два пов’язані?  

Давайте спробуємо зрозуміти, що таке 3 будівельні блоки Nest.JS і що кожен з них робить.

1. Модулі: Nest.JS структурований таким чином, що ми можемо розглядати кожну функцію як модуль. Наприклад, усе, що пов’язано з Користувачем, як-от моделі, контролери, DTO, інтерфейси тощо, можна відокремити як модуль. Модуль має контролер і купу провайдерів, які є вбудованими функціями, як-от служби, orm, emailer тощо.

2. Контролери: Контролери в Nest.JS є інтерфейсами між мережею та вашою логікою. Вони використовуються для обробки запитів і повернення відповідей клієнтській стороні програми (наприклад, виклику API).

3. Провайдери (послуги): Постачальники – це ін’єкційні послуги/функції, які ми можемо вставити в контролери та інших постачальників, щоб забезпечити гнучкість і додаткові функції. Вони абстрагують будь-яку форму складності та логіки.

Узагальнити,

• У нас є контролери, які діють як інтерфейси (третій рівень чистої архітектури)
• У нас є провайдери, які можна впровадити для забезпечення функціональності (4-й рівень чистої архітектури: БД, пристрої тощо)
• Ми також можемо створювати служби та репозиторії, щоб визначити наш варіант використання (2-й рівень)
• Ми можемо визначити наші сутності за допомогою постачальників БД (1-й рівень)

Висновок:

Nest.JS — це потужний фреймворк Node.JS і найвідоміший на сьогоднішній день машинопис. Тепер, коли ви ознайомилися з цим фреймворком, ви, мабуть, думаєте, чи можемо ми використовувати його для створення структури проекту з чистою архітектурою. Ну, відповідь - Так! Абсолютно. як? Я поясню в наступній серії цієї статті. 

А поки залишайтеся з нами!

Про автора:

Джунайд Бхат зараз працює технічним керівником у Mantra Labs. Він ентузіаст технологій, який щодня прагне стати кращим інженером, дотримуючись галузевих стандартів і орієнтуючись на більш структурований підхід до вирішення проблем. 

Читайте наш останній блог: Framework Golang-Beego та його застосування

Знання, які варті того, щоб доставити у вашу поштову скриньку