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

Кратко¶

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

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

Приоритет: платформа не строится отдельно. Она эволюционирует из Алатырь Сервис, потому что там уже заложены базовые сущности мультитенантности, изоляция данных и membership.

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

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

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

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

Миграция моно → мульти — самая дорогая миграция в SaaS. Требует переписать десятки таблиц, все запросы и код доступа. Проходить это позже, имея реальных клиентов, — запрет на релизы на месяцы.
Заложить с самого начала — небольшая надбавка к цене разработки, зато нет катастрофической миграции в будущем.
В Alatyr Service базовый якорь мультитенантности уже сделан.

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

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

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

Модуль	Отвечает за
Аутентификация	Регистрация, вход, сессии, восстановление пароля
Тенанты	Список арендаторов, tenant scope в каждом запросе, membership
Пользователи	Профили, контакты, привязка к нескольким тенантам
Роли и права	Роли (админ, менеджер, мастер, клиент), права доступа
Биллинг	Тарифы, подписки, лимиты, счета, платёжка
Кабинет	Личный кабинет пользователя — универсальный контейнер вкладок
Уведомления	Email, мессенджеры, push — единая точка отправки
Файлы	Загрузка, хранение и выдача файлов с изоляцией по тенанту
Аудит	Аудит-лог действий (кто что когда изменил)

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

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

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

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

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

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

Backend: Node.js + TypeScript, REST-API
База данных: переход на промышленную СУБД в рамках эпика мультитенантности
Frontend: React + TypeScript + Tailwind
Файлы: отдельный сервис хранения за приватным контуром
Деплой: systemd + nginx + CI из GitHub
Секреты: менеджер секретов на собственной инфраструктуре
RAG/AI: локальная связка LLM + векторная БД + UI на сервере знаний

Дорога¶

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

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

Что закладываем:

Тенант-скоуп во всех ключевых таблицах CRM
Middleware, автоматически инжектирующий tenant scope
Membership пользователей в тенантах
Изоляция файлового хранилища по тенанту
Аудит cross-tenant запросов

Критерий готовности: внутри Alatyr Service работают несколько арендаторов, полная изоляция данных, ни один API-запрос не проходит без tenant scope.

Фаза 2 — выделение core-модулей¶

Рефакторим то, что стало общим, в отдельные пакеты или подсервисы. Первые кандидаты: аутентификация, тенанты, универсальный кабинет, уведомления.

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

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

Публичный self-serve onboarding нового арендатора
Тарифная модель и её enforcement
Экспорт-импорт данных арендатора
On-premise инсталляции для клиентов с профилем ФСТЭК
Кросс-tenant коллаборация подрядчик-заказчик

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

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

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