Платформа «Алатырь»¶

Кратко¶

Цель: через 2 года иметь платформу, на которой:

Работают все свои проекты (Сервис, Таверна, DeFi-анализатор, глэмпинг-CRM и т.д.) — как арендаторы одной инфраструктуры
Можно продавать инсталляции сторонним бизнесам (внешняя техническая служба, малые сервисные компании) — как SaaS-продукт

Приоритет: платформа не строится отдельно. Она эволюционирует из Алатырь Сервис, потому что там уже сделан эпик MT (Multi-Tenancy) и заложены таблица tenants, изоляция данных и membership.

Бизнес-приоритет: фундамент → Алатырь Сервис как денежный поток → коммерциализация платформы. Горизонт последнего пункта — 2 месяца или 2 года, не критично.

Ключевое архитектурное решение: multi-tenant с день-1¶

Что это значит: каждая таблица бизнес-данных содержит tenant_id. Каждый API-запрос знает своего арендатора (через токен). Middleware автоматически ограничивает запросы данными этого арендатора.

Почему сейчас, а не потом:

Миграция моно → мульти = самая дорогая миграция в SaaS. Требует переписать десятки таблиц, сотни SQL-запросов, весь код доступа. Проходить это в 2027-м, имея реальных клиентов = запрет на релизы на 2-3 месяца.
Заложить с самого начала = +5-10% к цене разработки, но защищает от миграции.
У Alatyr Service это уже сделано — эпик MT, MT-01 ввёл production-таблицу tenants с ULID.

Что уже готово (Alatyr Service):

Production-таблица tenants с ULID (MT-01, merged)
Seed 1:1 из own_companies (ИП Головин Р.Ю. и ИП Головин А.Р. — уже два «внутренних тенанта»)
Read-only доступ через API
Планировщик эпика МТ на 17 задач (MT-02..17) для полного перехода

Модель модулей¶

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

Имеет собственные таблицы БД (с tenant_id)
Даёт REST/RPC API
Даёт UI-компоненты (React)
Может включаться/выключаться на уровне арендатора

Core-модули (общие для всех продуктов)¶

Модуль	Отвечает за	Статус
`auth`	Регистрация, вход, сессии, восстановление пароля, JWT/session	В работе (Alatyr Service)
`tenants`	Список арендаторов, tenant_id в каждом запросе, membership	MT-01 ✓, MT-02..06 backlog
`users`	Профили, аватары, контакты, привязка к нескольким тенантам	Частично (Alatyr Service)
`rbac`	Роли (admin/manager/master/client), права доступа	Есть в Alatyr Service
`billing`	Тарифы, подписки, лимиты, счета, платёжка	Не начато (MT-07, MT-12)
`cabinet`	Личный кабинет пользователя — универсальный контейнер вкладок	Не начато
`notifications`	Email, Telegram, push — единая точка отправки	Частично (Telegram-уведомления Alatyr Service)
`files`	Загрузка, хранение, выдача файлов через `alatyr-storage-api` с tenant-scope	MT-05 backlog
`audit`	Аудит-лог действий (кто что когда изменил)	MT-06 backlog

Domain-модули (специфичные для типа продукта)¶

Модуль	Для чего	Пример продукта
`crm`	Клиенты, заявки, объекты, договоры, счета	Алатырь Сервис
`catalog`	Каталог товаров/услуг с ценами и остатками	Алатырь Сервис, Печать
`tavern-scene`	Главный зал, NPC, диалоги	Алатырь Таверна
`defi-scanner`	Мониторинг DEX-цен, арбитражные сигналы	DeFi-анализатор
`booking`	Календарь брони номеров/мастерских	Глэмпинг, Печать

Domain-модули опциональны на уровне арендатора: клиент «сервисная компания» включает crm+catalog, клиент «загородный отель» — booking+catalog.

Как это укладывается в текущие проекты¶

Алатырь Сервис = продукт-локомотив. Основной денежный поток, первый арендатор платформы. Уже фактически строится как платформа. Продолжаем как есть.
Алатырь Таверна = второй арендатор. Сейчас статический — идеально: перевод на общий core пока не блокирует Таверну. Когда backend Таверны включится обратно, он будет строиться поверх core-модулей платформы.
DeFi-анализатор = ещё один арендатор с одним domain-модулем (defi-scanner) поверх общего кабинета.
Глэмпинг = долгосрочно тоже арендатор с booking+catalog.
Печать = арендатор с catalog+booking (заказы + очередь).

Технологический стек (наследуется от Alatyr Service)¶

Backend: Node.js + TypeScript, Express (или Fastify), REST-API
База: SQLite сейчас → PostgreSQL после MT-эпика (уже запланировано в Alatyr Service)
Frontend: React + Vite + TypeScript + Tailwind + Zod
Файлы: отдельный alatyr-storage-api за nginx/AmneziaWG (уже работает)
Деплой: systemd + nginx + GitHub Actions (уже работает)
Секреты: Vaultwarden (уже работает)
RAG/AI: Ollama + Qdrant + OpenWebUI на ragserver (уже работает)

Дорога¶

Фаза 1 — фундамент MT в Alatyr Service (сейчас)¶

Что делаем: проходим эпик MT в Alatyr Service. Это и есть создание платформенного ядра — просто оно живёт в одном репозитории с продуктом «Сервис».

Приоритетные задачи из эпика MT (см. проект Алатырь Сервис):

MT-02 — tenant_id во все ключевые таблицы CRM (objects, contracts, requests, ...)
MT-03 — middleware, автоматически инжектирующий tenant_id
MT-04 — membership-таблица tenant_memberships
MT-05 — изоляция файлового хранилища по tenant
MT-06 — аудит tenant-cross запросов

Не делаем сейчас: MT-13 (public self-serve), MT-15 (импорт), MT-16 (on-premise), MT-17 (кросс-tenant коллаборация). Это фаза 3.

Критерий готовности: внутри Alatyr Service работает 2+ арендатора (ИП Р.Ю. и ИП А.Р.), полная изоляция данных, ни один API-запрос не проходит без tenant scope.

Фаза 2 — выделение core-модулей (после Фазы 1)¶

Что делаем: рефакторим то, что стало общим, в отдельные npm-пакеты или отдельные подсервисы. Первые кандидаты:

@alatyr/core-auth — модуль аутентификации
@alatyr/core-tenants — таблица tenants + middleware
@alatyr/core-cabinet — универсальный личный кабинет (вкладки Заявки, Договоры, Счета, Настройки)
@alatyr/core-notifications — единая точка Email/Telegram

Технически: monorepo (pnpm workspaces или Turborepo) или отдельные репы. Решение принимаем в конце Фазы 1.

Критерий готовности: можно создать новый продукт (Таверна backend, глэмпинг MVP) на общих core-модулях без копипаста.

Фаза 3 — коммерциализация платформы (когда денежный поток стабилен)¶

Публичный self-serve onboarding (MT-13)
Тарифная модель и enforcement (MT-07, MT-12)
Экспорт-импорт данных арендатора (MT-14, MT-15)
On-premise инсталляции для КИИ/ФСТЭК-клиентов (MT-16)
Кросс-tenant коллаборация подрядчик-заказчик (MT-17)

Триггер входа в фазу 3: Alatyr Service приносит стабильный доход и покрывает операционные расходы платформы; появляется первый внешний потенциальный клиент.

Риски и что делаем чтобы их снизить¶

Риск размытия фокуса: соблазн начать «строить платформу» отдельно от Сервиса, потратить полгода на фреймворк и не заработать. Митигация: платформа = побочный эффект правильной архитектуры Сервиса. Отдельного проекта «платформа» до Фазы 2 не существует.
Риск over-engineering: заложить сложное multi-tenant, а по факту у тебя один арендатор ещё год. Митигация: заложить только схему БД и middleware. Не строить UI-конструктор тенантов, self-serve onboarding, тарифы — пока это не нужно.
Риск tenant data leak: ошибка в middleware = чужие данные попадают клиенту. Юридически катастрофично. Митигация: MT-06 (аудит cross-tenant) с день-1, автотесты на изоляцию, code review для любого запроса без явного tenant_id.
Риск смешения бренда: если Таверна и Сервис станут «одинаковыми», Сервис потеряет корпоративный вид. Митигация: platform ≠ UI. Каждый арендатор имеет собственный бренд, домен, тему; общими являются backend и модули.

Следующие шаги¶

Утвердить этот документ (обсудить со свежей головой)
Проверить приоритеты в эпике MT в Alatyr Service — тот ли порядок задач
Начать MT-02 (tenant_id в таблицы CRM) — это первая техническая работа