Эта статья была первоначально опубликована здесь.
Основной принцип сервисно-ориентированной архитектуры заключается в разделении задач, чтобы перенести бизнес-логику и уязвимый слой данных непосредственно на маршруты API. При этом мы изолируем различные части логики таким образом, чтобы это имело смысл.
В этой трехслойной или многоуровневой системе мы обычно разделяем логику маршрута или функции приложения на контроллер, сервис и уровень доступа к данным.
Контроллер (маршруты)
Его цель — обрабатывать запросы от пользователя к приложению и работать с различными маршрутами, имеющими разные функции. Он также изменяет входящие данные от пользователя, чтобы их можно было использовать в нашей бизнес-логике.
Он также отвечает за возврат обработанных или запрошенных данных пользователю в подходящем формате. Как правило, механизм маршрутизации контролирует, какой запрос попадает к какому контроллеру.
Очень заманчиво поместить бизнес-логику внутри контроллеров, но рекомендуется этого не делать, поскольку по мере роста вашего приложения она быстро станет чрезмерной, а спагетти-код внутри контроллера может просто затмить истинную цель контроллеров и сделать наше приложение уязвимым и гораздо менее удобным для обслуживания.
Сервисы ~ Логика
Здесь находится фактическая логика приложения, она содержит наши операции CRUD, валидацию, аутентификацию и авторизацию пользователей и данных. Это уровень бизнес-логики, где обрабатываются данные от пользователя, которые сервис получает от контроллера, а уровень доступа к данным вызывается для возврата данных пользователю.
Основным преимуществом такого разделения бизнес-логики является то, что наша кодовая база становится гораздо более удобной для обслуживания, мы пишем чистый код и допускаем гораздо меньше ошибок.
Сервисный уровень — это настоящее сердце или ядро нашего приложения, в нем содержится вся магия приложения, например, приложение генерирует счета на основе данных пользователя, именно здесь генерируется счет, данные сохраняются, а ответ отправляется пользователю через контроллер.
Уровень доступа к данным
Это уровень, на котором происходит изменение, чтение и удаление логики, связанной с нашими данными, хранящимися в какой-то базе данных. Он не имеет жесткой структуры, как два других. Под структурой я подразумеваю то, что контроллеры и сервисы размещаются в разных файлах, но на самом деле это некий ORM, например prisma или mongoose, который **может работать с хранимыми данными.
Зачем это использовать?
Самым распространенным вопросом в вашем уме будет: почему я должен использовать это, а не поместить всю логику в одну функцию или, так сказать, слой. Я знаю, что персистирование делает кодовую базу более управляемой, но это не такая уж веская причина, чтобы так поступать, например, для небольших проектов с меньшим количеством логики и маршрутов.
Чтобы убедить вас в необходимости использования этого подхода, вот некоторые преимущества 3-уровневой архитектуры:
-
Масштабируемость
Это делает наше приложение намного легче, и это делает его намного более масштабируемым.
-
Простая интеграция
Когда вы создаете приложение, оно, вероятно, использует какую-то стороннюю библиотеку или общается с каким-то другим приложением, чтобы отправить ответ пользователю. Эта архитектура, основанная на сервисах и способствующая разделению логики, отлично справляется с этой задачей.
-
Безопасность
Такой подход к проблеме является наилучшим, поскольку он проверяет данные снова и снова и снижает вероятность попадания вредоносных данных в наше приложение, так как данные изменяются и проверяются на каждом контрольном уровне, поэтому без каких-либо дополнительных усилий это дает вам преимущество в безопасности.
-
Тестирование
Это также значительно облегчает тестирование приложения, поскольку логика изолирована от сервисов, а контроллеры могут быть легко проверены, что приводит к простоте тестирования и меньшему количеству ошибок в вашем приложении.
-
Многоразовый код
На разработчиков часто давят тем, что они должны писать DRY (не повторяйся) код, эта архитектура на основе сервисов идеально подходит для повторного использования кода, например, сервис может быть использован в нескольких контроллерах или других сервисах с помощью таких методов, как инъекция зависимостей и т.д.
Так ли это хорошо?
Сервис-ориентированная архитектура не подходит для всех видов использования, в некоторых случаях ее применение может стать катастрофой.
Одним из основных ее недостатков являются высокие накладные расходы и высокая начальная стоимость.
-
Высокие накладные расходы
Эта архитектура имеет высокие накладные расходы в приложении, и не только в памяти, но и в опыте разработчика, так как для ее работы требуется много шаблонного кода.
-
Высокие инвестиции
Эта архитектура требует больших инвестиций денег и времени с самого начала. Она требует различных ролей разработчиков для каждого уровня, а также требует много времени на разработку.
Стоит ли мне ее внедрять?
Главный вопрос заключается в том, стоит ли мне на самом деле внедрять эту богатую шаблонами, безопасную и сложную архитектуру? На этот вопрос нельзя ответить просто так. Вы должны принять это решение самостоятельно, исходя из ваших требований, размера проекта, бюджета и времени.
Если вы создаете небольшое приложение, состоящее из нескольких маршрутов и некоторой логики, вам не стоит принимать эту архитектуру, поскольку ее поддержка для такого маленького проекта станет мучением.
Но если вы хотите создать очень сложный большой проект с большим количеством маршрутов и тоннами логики, это может быть подходящим вариантом для вас.
В любом случае, вы должны решить это сами. Есть несколько действительно хороших фреймворков, которые значительно упрощают начало работы, например NestJS и Spring Boot для API и Backend Stuff и AngularJS для клиентской части.