Архитектура программного решения

Программное решение Hi.Work должно придерживаться современных тенденций касательно разработки крупных многопользовательских приложений. Архитектура разрабатывается относительно требований заказчика:

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

В связи с этими требованиями, были определены следующие основные технологические подходы:

Компьютерные сети - так как открывают пользователям круглосуточный доступ по стандартным каналам связи
WebAPI - поддерживает стандартные и распространённые протоколы HTTP и WebSocket, а так же представляет информацию в формате JSON (так же gRPC для взаимодействия между микросервисами)
Микросервисный подход - позволяет декомпозировать сложную систему на составные логические модули, разработку которых можно вести параллельно и с малой зависимостью
Реляционные базы данных - структурирование данных и индексация для быстрой выборки, управления транзакциями и
Документоориентированные базы данных - для хранения данных с простой структурой, малой связностью и необходимостью быстрого доступа
Брокеры собщений - позволяют внедрить стандартизированный канал связи для взаимодействия между сервисами приложения, оркестрации их работы и своевременном оповещении о событиях в режиме реального времени
WEB-ориентированность: клиентские приложения с поддержкой HTML/CSS/JS являются кроссплатформенными в связи с их распространённостью и доступностью для различных типов устройств

Программное решение реализует клиент-серверную ахитектуру:

Backend - функционал и бизнес-логика, доступная по запросам к серверу
Frontend - клиентские приложения, которые используют Backend-сервер для отправки запросов к бизнес-функциям системы

Пользователи системы

Были определены следующие роли для пользователя системы:

Сотрудник - пользователь, который отслеживает данные о своей карьере, получает задания, управляет своими навыками и т.п.
HR-менеджер - пользователь, который управляет общими данными о карьерных треках, должностях, навыках организации и т.п. - является административным
Куратор - пользователь, который является руководителем сотрудника и может выдавать задания, отслеживать деятельность подчинённого и т.п.

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

Подсистемы - разграничение клиентских приложений

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

Приложение для сотрудника
Приложение для менеджера (HR, куратор)

Серверная часть - backend-архитектура

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

Реляционная база данных - не доступна напрямую, используется только WebAPI
WebAPI - http-сервер с запросами, которые предназначены для внесения изменений и/или получения данных в формате JSON, а так же других ресурсов
ИИ-модуль - один из внешних сервисов (может быть развёрнут локально или доступен по сети интернет) для анализа данных и составления отчётов

Безопасность - доступ к функционалу и ресурсам

Доступ к ресурсам осуществляется только авторизованным пользователям, прошедшим авторизацию. Современным стандартом аутентификации и авторизации для распределённых сетевых приложений является OAuth, который описывает стандарты для подтверждения пользователя и его прав. Одной из описываемых технологий явлется JWT (Json Web Token). Так же для уменшения рисков, связанных с доступом злоумышленников к авторизационным данных пользователей, необходимо сохранять только отпечаток пароля с помощью алгоритмов хеширования. Для усложнения перебора данных при нахождении закономерностей алгоритма, в приложении реализуется "соление паролей" ("хеш-соль").

Общая схема архитектуры

Технологии доставки и развёртывания

Для организованной разработки в рамках команды разработчиков, вносятся следующие технологические решения:

Система версионирования Git
Централизованный репозиторий GitHub
Система контейнеризации Docker
Система оркестрации контейнеров Docker Compose
Своевременная поставка изменений в контейнеры посредством GitHub Actions и GitHub Container Registry (GHCR)