Основные понятия

Основные понятия#

В этой главе описаны основные понятия необходимые для понимания организации разработки.

Решение#

Дистрибутив решения это набор скомпилированных библиотек (jar-файлов) устанавливаемых в сервер приложения. Решение предоставляет весь перечень прикладной бизнес-логики необходимой для работы сервера приложения.

Системные требования#

  • Установленный сервер приложения GlobalFramework.

  • Доступ к базе данных PostgreSQL.

Дистрибутив сервера приложения#

Дистрибутив сервера приложений представляет из себя архив содержащий набор файлов необходимый и достаточный для запуска решений.

Системные требования#

  • Java на базе OpenJDK 1.8.

Модуль#

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

Модуль содержит:

  • Классы - описание атрибутов таблицы, и бизнес-логика обработки строк.

    Подробнее смотри:

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

    Подробнее смотри:

  • Поставочные данные - данные и скрипты для установки в БД при первом запуске решения.

  • Скрипты миграции - скрипты комплексного обновления схемы базы данных и модуля при первом запуске новой версии решения

Зависимости#

Модуль может содержать зависимости от другим модулей:

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

  • Динамическая зависимость:
    При этом доступ к дочернему модулю возможен только через jexl скрипты. Jexl скрипты ограничивают возможности совместного использования кода, часто неявно требуя специализированных фасадов для взаимодействия. Однако это позволяет выпускать релизы модулей независимо друг от друга.

Проектный модуль#

Модуль, содержащий в себе конфигурацию решения, модуль содержит:

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

  • Конфигурацию проектных переопределений - можно переопределить контроллеры классов и выборок.

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

Репозиторий библиотек#

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

  • репозиторий библиотек;

  • репозиторий комплектов сборки - используется в случае, если проект собирается на основе комплекта сборки.

Примечание

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

Комплект сборки#

Набор одновременно выпускаемых артефактов, достаточный для сборки проекта. Базовый комплект сборки содержит:

  • сервер приложений;

  • плагин сборки - используется для расширения стандартной функциональности sbt;

  • базовые модули.

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

База данных#

Для хранения транзакционных данных используется база данных PostgreSQL.

Системные требования#

Конфигурация решения#

Позволяет настраивать поведение решения без привлечения программистов.
В основном содержит:

  • настройки типов;

  • печатные формы;

  • настройки электронных подписей для пользователей;

  • права доступа;

  • универсальные характеристики;

  • универсальные справочники.

Создание базы данных для разработки#

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

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

  • Использование полных релизов конфигурации.

  • Клонирование базы разработки с настроенной конфигурацией решения
    В простейшем случае достаточно снятия и установки дампа схемы public.

Создание тестовой базы данных#

Тестовая база может быть создана от рабочей базы. В простейшем случае достаточно снятия и установки дампа схемы public.

Шаблон ландшафта#

  • common_dev - центральный проект разработки. На нем разрабатываются базовые версии модулей. И выпускаются релизы коробочных решений.

  • project_dev - проектная база разработки, осуществляется детальная настройка модулей и интеграций по ТЗ заказчика. Производится тестирование.

  • project_test - тестирование решения на мощностях заказчика.

  • project_prod - рабочий контур заказчика.

Файловое хранилище#

Используется для хранения прикрепленных файлов отдельно от БД. Это позволяет существенно снизить нагрузку на базу данных.

Доступ к файловым хранилищам настраивается в приложении: Настройка системы \  Сущности > Файловые хранилища

В дополнительных операциях есть следующие операции:

  • Проверить чтение и запись в хранилище
    Запрашивается размер файлов в Килобайтах, по умолчанию: 1. После чего запускается тест:

    1. В течение одной минуты создаются файлы указанного размера. Наполнение файлов — случайный текст, файлы все одинаковые. Генерация наполнения файла не включается во время теста (текст генерируется до создания файлов).
      Фиксируется количество созданных файлов.

    2. Чтение созданных файлов. Содержимое читается в переменную и так по всем файлам. Фиксируется время чтения всех созданных в п.1 файлов.

    3. Удаление созданных файлов. Фиксируется время удаления всех созданных в п.1 файлов.

Содержание