хорош ли такой подход в архитектуре проекта?

В своих проектах API - я использую паттерн Controller -> Service -> Model. В простых проектах достаточно описать все функций в одном файле.
user.controller.js

const ApiError = require('../error/ApiError');
const yup = require('yup');
...

exports.login = (req, res, next) => {...}
exports.signup = (req, res, next) => {...}
exports.getInfo = (req, res, next) => {...}
exports.changePassword = (req, res, next) => {...}

Но когда проект развивается, то соответственно растет код, и хранить все в 1 файле становится неудобно. Например когда файл состоит из 500 строк кода и нужно изменить где то 1 строчку кода, то приходится скроллить вниз, что очень неудобно.
Я решил, а что если каждую функцию разделить на под файлы и подключать в итоге все в index.js

controllers/user/
- index.js (Единая точка входа для всех функций);
- login.js;
- signup.js
...

и получается что то вроде
controllers/user/login.js

const ApiError = require('../error/ApiError');
const yup = require('yup');
...

module.exports = (req, res, next) => {...}

controllers/user/index.js

const login = require('./login');
const signup = require('./signup');
...

module.exports = {
 login,
 signup 
};

Теперь намного удобней редактировать функций, и все они хранятся в одной точке.
Как вы считаете мой подход к проектированию нормальный или есть что то похожее?


Ответы (1 шт):

Автор решения: Лукас

Я пришел к такому выводу, что все таки лучше использовать архитектуру, которая была описана мною в вопросе.
Пример, когда это вам поможет:

  • Удобно работать с кодом. Понятно что и где находится.
  • Ваш проект всегда должен иметь возможность расширяться. Соответственно хранить код все в 1 файле уже неправильно. Если это Rest Api ? - то часто бывает, что меняется бизнес логика и появляются роутеры вида /api/v1/users, /api/v2/users.
  • С большим кол-ом кода другие программисты не будут мучаться.
→ Ссылка