Документация Adapstory

Что принадлежит каждому core-BC, что он отдаёт и какие даёт гарантии.

Ядро Adapstory — это шесть bounded contexts. Каждый работает как отдельный сервис со своей PostgreSQL. Межконтекстное взаимодействие — REST или Kafka, без shared-таблиц.

BC-01 — Plugin Gateway

Принадлежит: реестр MCP-инструментов, маршрутизация LLM, применение guardrails, бюджетирование токенов.

Для вас важно: MCP-инструменты каждого плагина регистрируются здесь. Когда LLM в платформе вызывает инструмент, этот BC маршрутизирует запрос, проверяет бюджет тенанта, применяет guardrails и возвращает ответ.

Контракт:

Регистрация: POST /bc-01/mcp/tools (от Plugin Lifecycle на install-time)
Вызов: POST /bc-01/mcp/invoke (от LLM через Gateway)
Проверка бюджета: fail-closed если тенант превысил лимит

BC-02 — Plugin Lifecycle

Принадлежит: манифесты плагинов, state machine установки/обновления/отката, верификация подписи образа.

Для вас важно: это BC, с которым вы общаетесь при публикации новой версии. Он проверяет Cosign-подписи, применяет политики Kyverno и вызывает BC-19 для планирования.

State machine:

DRAFT → SIGNED → VERIFIED → INSTALLING → ACTIVE
                                    ↘ FAILED → ROLLED_BACK

BC-10 — Identity

Принадлежит: пользователи, тенанты, роли, конфигурация SSO. Под капотом — Keycloak.

Для вас важно: когда плагину нужно знать кто его вызывает, читайте JWT-claims — не обращайтесь к BC-10 напрямую, за исключением резолва ролей, которых у вас ещё нет.

BC-15 — Data Model Engine

Принадлежит: динамическая схема. Тенанты могут расширять модель (добавлять сущности, атрибуты) в runtime. BC-15 сохраняет согласованность схемы, данных и проекций событий.

Плагины, расширяющие core-сущности (например, добавляющие атрибут к course), регистрируют расширения здесь. Data Model Engine обеспечивает совместимость и версионирует миграции схемы как код.

Основной API:

POST /bc-15/entities/{type} — создать
PATCH /bc-15/entities/{type}/{id} — частичное обновление (под капотом CloudEvents)
POST /bc-15/schemas/{type}/migrations — опубликовать изменение схемы

BC-16 — Identity Runtime

Принадлежит: короткоживущие JWT, introspection токенов, per-tenant ключи подписи.

Для вас важно: валидируйте входящие JWT через этот BC (или используйте shared-libs, которые оборачивают его). Не храните токены. Ротируйте ключи агрессивно.

BC-19 — Multi-Tenant Runtime

Принадлежит: планирование, изоляция, инъекция секретов, лимиты ресурсов.

Для вас важно: это то, что запускает ваш плагин. Он решает какой node, какой namespace, какие секреты маунтить. Вы декларируете лимиты в plugin.yaml; он их обеспечивает.

Гарантии:

В tenant namespaces pod-security.kubernetes.io/enforce: restricted
Секреты идут по пути Vault → ESO → Kubernetes Secret. Никогда в образах.
Network policies по умолчанию запрещают cross-tenant трафик.

Место плагина

Плагины живут вне ядра. Они интегрируются через:

Вызовы core-API по HTTP (с service-account JWT от BC-16).
Produce/consume Kafka-событий в формате CloudEvents.
Регистрация MCP-инструментов в BC-01 для вызовов от LLM.

Они не:

Открывают прямые DB-подключения к core-BC.
Делят in-memory state с другими плагинами.
Обходят LLM Gateway для вызовов моделей.

Далее: Quickstart по плагину.

Bounded contexts