Перейти к основному содержанию
`Ctrl`+`K`

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

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

## Решение

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

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

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

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

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

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

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

- Java на базе OpenJDK 1.8.

## Модуль

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

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

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

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

  - Классы;

  - Сервисы класса;

  - Тип объекта.

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

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

  - Выборка.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

## База данных

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

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

- PostgreSQL 12 и выше.

- Расширения БД.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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