Источник: Gist by Sasha Zmts

Date: 2019-12-17

https://i.imgur.com/EGp4qfC.jpg

node.js

TL;DR

code: https://github.com/zmts/supra-api-nodejs

Предисловие

Одной из болезней Node.js комьюнити это отсутствие каких либо крупных фреймворков, действительно крупных уровня Symphony/Django/RoR/Spring. Что является причиной все ещё достаточно юного возраста данной технологии. И каждый кузнец кует как умеет ну или как в интернетах посоветовали. Собственно это моя попытка выковать некий свой подход к построению Node.js приложений.

Несколько слов что такое архитектура (IMHO):

Архитектура - набор подходов для организации программно-аппаратного комплекса.
Описание компонентов системы и взаимосвязей между ними.

Несколько слов про разделение приложения на слои:

Обычно в слое Контроллеров данные из запроса валидируются и приводятся к виду необходимому для последующего сервисного слоя. В свою очередь сервисный слой полностью изолирует бизнес логику и возвращает результат вычислений в контроллер. Или иначе ? Как вы считаете ? И так каждый программист делает как считает нужно либо так как привык. Давайте будем откровенны. Приводило ли подобная архитектура к тому ради чего задумывалась(к порядку и разделению логики) ? Зачастую все эти попытки сводятся к big ball of mud. Зачастую в контроллер просачивается бизнес логика, а в сервисный слой валидация, а то и вообще контекст запроса. Дабы так не происходило данный подход предлагает использовать единый слой для всей логики касаемо конкретного use case. Назовем этот слой Action layer. В итоге имеем:

  1. Минималистичный контроллер - сугубо маппинг экшенов на роуты
  2. Слой экшенов отвечающий за валидацию, всевозможные проверки доступа(владелец/не владелец/админ/не админ/аноним…) и бизнес логику
  3. Data layer - прослойка к БД
Controller(роутинг, проверка прав по роли) >>
Action(проверка прав по id, схема валидации запроса, логика юзкейса) >>
Data Layer(биндинги к БД)

Содержание