Эта статья была первоначально опубликована здесь.

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

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

SOA-архитектура


Контроллер (маршруты)

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

Он также отвечает за возврат обработанных или запрошенных данных пользователю в подходящем формате. В общем, механизм маршрутизации контролирует, какой запрос попадает в какой контроллер.

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


Услуги ~ Логика

Именно здесь находится фактическая логика приложения, она содержит наши операции CRUD, проверки, аутентификацию и авторизацию пользователей и данных. Это уровень бизнес-логики, где обрабатываются данные от пользователя, которые служба получает от контроллера, а уровень доступа к данным вызывается для возврата данных пользователю.

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

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


Уровень доступа к данным

Это уровень, на котором логика, связанная с нашими данными, сохраненными в какой-то базе данных, модифицируется, читается и удаляется. У него нет такой жесткой структуры, как у двух других. И что я имею в виду под структурой, так это то, что контроллеры и службы помещаются в разные файлы, но на самом деле это своего рода ORM, например призма или мангуст который ** может общаться с сохраненными данными.


Зачем это использовать?

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

Чтобы убедить вас в использовании этого подхода, вот несколько преимуществ этой трехуровневой архитектуры:

  • Масштабируемость

    Это делает наше приложение намного легче и делает его намного более масштабируемым.

  • Простая интеграция

    Когда вы создаете приложение, оно, вероятно, использует какую-то стороннюю библиотеку или общается с каким-то другим приложением, чтобы отправить ответ пользователю. Эта сервисная архитектура, которая способствует разделению логики, отлично справляется с этим.

  • Безопасность

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

  • Тестирование

    Это также значительно упрощает тестирование приложения, поскольку логика изолирована от служб, а контроллеры можно легко проверить, что упрощает тестирование и снижает количество ошибок в приложении.

  • Многоразовый код

    Разработчиков часто угнетает тот факт, что они должны писать СУХОЙ (не повторять себя) код, эта сервисная архитектура идеально подходит для повторного использования кода, например, сервис может использоваться в нескольких контроллерах или других сервисах с такими методами, как внедрение зависимоститак далее.


Это так хорошо?

Сервис-ориентированная архитектура не подходит для всех видов использования, в некоторых случаях ее принятие может оказаться катастрофой.

Одним из его основных недостатков являются высокие накладные расходы и высокая начальная стоимость.

  • Высокие накладные расходы

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

  • Высокие инвестиции

    Эта архитектура требует больших вложений денег и времени с самого начала. Это требует разных ролей разработчиков для каждого уровня, а также требует много времени на разработку.


Должен ли я принять его?

Большой вопрос заключается в том, должен ли я на самом деле использовать эту богатую шаблонами, безопасную и сложную архитектуру? На этот вопрос нельзя ответить только этим. Вы должны принять это решение самостоятельно, исходя из ваших требований, размер проекта, бюджет и время.

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

Но если вы хотите создать очень сложный большой проект с большим количеством маршрутов и тоннами логики, он может вам подойти.

В любом случае, вы должны решить это сами. Есть несколько действительно хороших фреймворков, которые значительно упрощают начало работы, например NestJS и Spring Boot для API и серверной части и AngularJS для клиентской стороны.