2.4.1 Microservices ui Platform Framework
Для реализации микрофронтенд архитектуры было принято решение использовать корпоративный фреймворк, реализующий паттерны микрофронтенд архитектуры — Microservices UI Platform Framework (MUI Platform Framework).
MUI Platform состоит из следующий компонентов [8]:
MUI Platform микросервис, представленный на рисунке 2, который предоставляет доступную по REST API Fragment Registry функциональность, необходимую для инициализации и деплоя фрагментов,
Java client библиотека, конфигурирующая фрагменты и их жизненные циклы,
Client runtime – mui-platform.js, предоставляющий функциональность для динамического рендеринга фрагментов,
Mui-platform-ngx-api – Angular библиотека, public API которой предоставляет интерфейсы для работы с фрагментами и MUI Platform в целом,
Mui-platform-development plugin – node.js express plugin, позволяющий имитировать работу MUI Platform в рамках локальной разработки.
В качестве примера взаимодействия с MUI Platform опишем процесс создания фрагмента, изображенный на рисунке 8:
Рисунок 8 – Создание фрагментов
В MUI Platform фрагмент представляет собой совокупность JS, CSS и дескриптора развертывания, благодаря которому реализуется сохранение информации обо всех зарегистрированных фрагментах в так называемом Fragment Registry и последующий доступ к ним по ID.
При загрузке Host-Application инициализирует MUI-Platform и для отрисовки фрагмента в дальнейшем вызывает инициирующий создание фрагмента метод API платформы, передавая в качестве параметра элемент DOM для отрисовки и ID фрагмента. MUI Platform “ищет” фрагмент с соответствующим ID в Fragment Registry и возвращает его JS и CSS bundle.
2.5 Архитектура данных
Поскольку Hiring будет являться одним из модулей корпоративного веб-приложения, у Hiring и этих модулей будет множество общих моделей данных, таких как сотрудник, офис, департамент, страна, город и так далее. В целях избежания дублирования программного кода в ходе разработки будет использована и доработана корпоративная Angular библиотека “Core”, в которой реализованы подобные модели данных и абстрактные классы сервисов с методами CRUD для этих моделей. Данные сервисы наследуются сервисами Host Application, реализующими их методы. В ходе разработки Hiring в Host Application будут реализованы новые сервисы. Для дальнейшего использования методов сервисов Host-Application во фрагментах, в том числе Hiring, эти сервисы размещаются в класс, который передается фрагментам с помощью декоратора @Input в HTML тэге <mui-fragment>. Также в Host Application реализованы сервисы, которые при загрузке Host-Application запрашивают у бэкенда наиболее часто используемые данные, такие как список всех сотрудников, стран и так далее, и хранят эти данные для дальнейшего использования их во фрагментах, минимизируя тем самым количество выполняемых запросов на бэкенд. Описанная выше функциональность Host Application будет доработана и использована в Hiring.
Поскольку в качестве спецификации для REST API была выбрана JSON: API, для удобства разработки все модели данных будут наследоваться от класса JsonApiResource (рисунок 9).
Рисунок 9 – JsonApiResource и JsonApiRelation
На рисунке 10 представлена архитектура данных Hiring. Многие из атрибутов моделей данных были скрыты для упрощения визуального восприятия диаграммы, полная диаграмма представлена на рисунке А2.
Рисунок 10 – Архитектура данных Hiring
Опишем модели данных представленные на рисунке 10:
- Модели, представляющие объекты бизнес-логики, которым соответствуют таблицы в базе данных микросервиса Hiring Microservice:
1) Hiring Request – модель “заявки на найм” сотрудника;
2) Relocation Info – модель, хранящая данные о возможной релокации сотрудника, для которого создан Hiring Request;
3) Employee Info – модель, хранящая личные данные сотрудника, для которого создан Hiring Request;
4) IT Equipment – модель, хранящая данные по выделяемому сотруднику, для которого создан Hiring Request, IT оборудованию;
5) IT Equipment Message – модель, хранящая данные с текстом и датой отправки нотификации “IT Equipment Approval Request”;
6) Employee Address – модель, хранящая данные об адресах места работы и места проживания сотрудника, для которого создан Hiring Request;
7) Hiring Employee Position – модель, хранящая данные о должности сотрудника, для которого создан Hiring Request;
8) Financial Info – модель, хранящая данные о финансовой составляющей Hiring Request’а сотрудника, для которого создан Hiring Request;
9) Attachment Document – модель данных, связывающая шаблон документа определенного типа (Paperwork Template) и загружаемые пользователем документы (Files);
10) File – модель данных, представляющая собой загружаемый пользователем документ;
11) Paperwork Template – модель данных, представляющая собой шаблон документа для заполнения;
- Вспомогательные модели данных, которые будут использованы для реализации отправки нотификаций и редактирования Hiring Request’а:
1) Notification Event;
2) Custom Notification Event;
3) Notification Model;
4) Changes.
- Модели данных, реализованные в библиотеке “Core”, которым соответствуют таблицы в базе данных микросервиса MasterData Microservice: Employee, Department, Country, State, Office, Currency, Site, Job Role, Legal Entity и Modification Fields. На диаграмме эти модели данных представлены в белом цвете.
Для реализации возможности получения объектов, указанных в relationships объекта, для которого выполняется запрос, будет использоваться написанная на LUA реализация агрегатора, представляющего собой интерцептор, обрабатывающий запросы по определенному URL. В конфигурации агрегатора для каждого объекта указано, в каком он расположен микросервисе и по какому URL, а также прописан маппинг для каждого из relationships объекта с объектами из конфигурации агрегатора, которые этим relationships соответствуют.