# Architecture

## Decision

Используем архитектуру `core + plugins`.

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

## Core

`core` содержит общие возможности платформы:

- `registry`: учет моделей, адаптеров, версий, лицензий и требований к ресурсам.
- `inference`: единый слой запуска моделей и совместимый API.
- `training`: общие пайплайны подготовки данных и дообучения.
- `evals`: общие правила оценки качества моделей.
- `deploy`: развертывание, включая GPU Docker host.
- `storage`: правила локального хранения моделей и датасетов.
- `monitoring`: метрики GPU, latency, ошибок и использования моделей.

`core` не должен содержать бизнес-логику конкретной задачи.

## Plugins

Плагины содержат прикладные направления:

- `text`: работа с текстом, суммаризация, анализ, генерация.
- `translation`: перевод.
- `audio`: speech-to-text, diarization, text-to-speech.
- `video`: извлечение кадров, аудио, анализ сцен и суммаризация.
- `image`: генерация изображений, inpainting и редактирование по маске.
- `1c`: помощник по 1С, BSL, запросы, метаданные, RAG и дообучение.

Каждый плагин должен иметь собственные:

- описание назначения;
- список моделей;
- пайплайны;
- датасеты;
- eval-тесты;
- настройки инференса;
- план будущего API.

## Plugin Boundary

Плагин может использовать `core`, но `core` не должен зависеть от конкретного плагина.

Правильное направление зависимости:

```text
plugins/* -> core/*
```

Неправильное направление:

```text
core/* -> plugins/*
```

## Growth Path

```text
Stage 1: one repository, core + plugins
Stage 2: heavy plugins run as separate containers
Stage 3: 1c/audio/video/image become standalone services
Stage 4: full service architecture if production load requires it
```