Архитектура API - Бизнес логики c тесно связаны с маршрутами?

Question

Чтобы ускорить разработку для моего следующего Node-API, я искал подходящую платформу. В прошлом я создавал свои API только с express.

Один шаблон проектирования, который я всегда считал полезным, - это полное отделение бизнес-логики c от обработки маршрутов в сервисах. Эти сервисы принимают только необходимую информацию (например, идентификатор пользователя или данные) и возвращают обещание, разрешающее результат операции.

Таким образом, легко использовать эти сервисы в других маршрутах, комбинировать их, тестировать или вызывать их на основе расписаний или других событий - полностью независимо от вызовов конечных точек. Маршрутизация и промежуточное ПО заботятся о контроле доступа, обработке ошибок и реагировании.

Глядя на документацию этих фреймворков (sails js, keystone js, ...), я в основном вижу бизнес-процессы. logi c тесно связан с отдельными маршрутами, напрямую принимает объекты запроса и обрабатывает ответы. Только в качестве запоздалой мысли кажется, что иногда предлагается способ извлечения «часто используемого кода» в вспомогательные функции.

Я что-то упустил? Почему этот шаблон является стандартом дизайна API? Это лучшая практика по причине?

Answer 1

Возможно, это связано с тем, что Node.js сервисов меньше по размеру. Если вы работаете в корпоративной среде, вам хорошо известно, что смешивание бизнес-логики c с кодом контроллера не поможет в долгосрочной перспективе. Возможно, небольшие проекты могут избежать этого, но как только размер увеличится, вы не сможете избежать физики. Лучше всего разделять проблемы и поддерживать поддерживаемость кодовой базы.

Я бы также добавил, что ниже сервисов хорошо иметь отдельный уровень, который обрабатывает взаимодействие с внешними границами процесса. Таким образом, вы можете тестировать бизнес-логику c изолированно, предоставляя соответствующие двойники для интеграций. Вот более подробное объяснение того, как это будет работать в проекте Node: Организация Node.js API-проекта с использованием 3-уровневой архитектуры .