---
doc_id: ARC-CK8S-DOMAIN-MAP-0001
type: architecture-domain-map
title: kodex — архитектурная карта доменов
status: active
owner_role: SA
created_at: 2026-04-26
updated_at: 2026-05-22
related_issues: [599, 600, 601, 602, 655, 747, 753, 322]
related_prs: []
approvals:
  required: ["Owner"]
  status: approved
  request_id: "owner-2026-04-26-platform-architecture-frame"
  approved_by: "ai-da-stas"
  approved_at: 2026-04-26
---

# Архитектурная карта доменов

## Кратко

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

## Принципы деления

- Один домен имеет один центр владения.
- Доменная карта содержит только домены с одним сервисом-владельцем.
- Сквозной процесс, который проходит через несколько сервисов-владельцев, не считается отдельным доменом-владельцем.
- Нативные сущности провайдера остаются у провайдера, а платформа хранит проекции и платформенные метаданные.
- Состояние среды исполнения не смешивается с агентной оркестрацией.
- Пользовательский интерфейс не становится владельцем данных и работает через пограничный слой и проекции чтения.
- Каталоги пакетов, руководящие пакеты, плагины и магазины пакетов относятся к одному пакетному контуру.
- Биллинг, релизы, риск, доступы и серверы проектируются как обязательные контуры, даже если реализуются поэтапно.

## Доменная карта

| Домен | Сервис-владелец | Каноническое состояние |
|---|---|---|
| Доступ и аккаунты | `access-manager` | Пользователи, организации, группы, членство, allowlist, права, внешние аккаунты как субъекты политики, ссылки на секреты и административный аудит. |
| Проекты и репозитории | `project-catalog` | Проекты, репозитории, проектная политика, `services.yaml`, источники проектной документации, правила веток, релизная политика, политика размещения. |
| Рабочие сущности провайдера | `provider-hub` | Зеркальные проекции `Issue`, `PR/MR`, комментариев, упоминаний, связей, webhook, сверка, лимиты и операции провайдера по разрешённым внешним аккаунтам. |
| Пакетная платформа | `package-hub` | Каталог пакетов, установленные пакеты, доступные пакеты, источники магазинов, пакеты плагинов, руководящие пакеты, версии и верификация. |
| Оркестрация агентов | `agent-manager` | Процессы, этапы, роли, привязки ролей к этапам, шаблоны промптов, сессии, агентные запуски, правила автоматизации, машина приёмки. |
| Серверы и кластеры | `fleet-manager` | Серверы, Kubernetes-кластеры, связность, здоровье, политика размещения и доступность инфраструктурных контуров. |
| Среда исполнения | `runtime-manager` | Слоты, задания, шаги заданий, сборка, выкладка, зеркалирование, предварительный прогрев, очистка и сроки хранения технических данных. |
| Риски и релизы | `governance-manager` | Риск-профили, оценка риска переходов, review signals, gate policy, gate requests, gate decisions, release decision package, release decisions и release safety-loop state. |
| Центр взаимодействий | `interaction-hub` | Диалоговые ветки, согласования, уведомления, подписки, попытки доставки, обратные вызовы внешних каналов. |
| Операционная консоль | `operations-hub` | Проекции чтения, ленты событий, очереди, блокировки, агрегированные статусы и операторские срезы. |
| Биллинг и учёт затрат | `billing-hub` | Биллинговые аккаунты, записи затрат, распределение затрат, основа счёта, экономика пакетов и SaaS-контур. |

## Сквозные процессы

Некоторые бизнес-процессы проходят через несколько доменов. Они не получают «общего владельца». Каждый сервис-владелец меняет только своё каноническое состояние, а сквозной процесс связывается доменными событиями, командами и проекциями чтения.

| Процесс | Владение по состоянию |
|---|---|
| Запуск агентной работы | `agent-manager` владеет агентным запуском и сессией; `runtime-manager` владеет слотом и заданием; `provider-hub` владеет зеркалом артефактов провайдера. |
| Релиз | `project-catalog` владеет релизной политикой, правилами веток и релизными линиями; `governance-manager` владеет release decision package, risk gates, release decision и release safety-loop; `agent-manager` владеет процессом подготовки и приёмки; `runtime-manager` владеет заданием выкладки; `interaction-hub` доставляет запросы решений и callbacks. |
| Риск и приёмка | `governance-manager` владеет risk profiles, оценкой риска, review signals, gate policy и решениями; `agent-manager` владеет результатом машинной приёмки и ожиданиями flow; `interaction-hub` доставляет запрос решения человеку; `project-catalog` хранит project/release policy и ссылки на risk profile; `runtime-manager` исполняет только технические задания по принятому решению. |
| Установка пакета | `package-hub` владеет установкой и версией пакета; `runtime-manager` владеет заданием запуска нагрузки плагина; `fleet-manager` владеет выбором инфраструктурного контура. |
| Доступ к проекту | `access-manager` вычисляет права и владеет политикой внешнего аккаунта; `project-catalog` владеет проектом и репозиторием; `provider-hub` исполняет операции провайдера по разрешённому внешнему аккаунту. |
| Жизненный цикл знаний | `project-catalog` владеет источниками проектной документации; `package-hub` владеет руководящими пакетами и шаблонами документов; `agent-manager` владеет запуском роли самоулучшения и результатом приёмки. |
| Самоулучшение руководства | `package-hub` знает пакет и версию; `agent-manager` запускает роль; `provider-hub` отражает PR в репозитории пакета. |

## Доменные события

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

Минимальные группы событий:
- `access.*`: организация, пользователь, группа, членство, действие доступа, право, поставщик внешних аккаунтов, внешний аккаунт;
- `project.*`: проект, репозиторий, `services.yaml`, релизная политика, политика размещения;
- `provider.*`: артефакт провайдера синхронизирован, рассинхронизация обнаружена, лимит изменился, требуется повторная авторизация;
- `package.*`: пакет обнаружен, установлен, обновлён, отозван, статус верификации изменился;
- `agent.*`: агентный запуск запрошен, состояние запуска изменилось, результат приёмки получен, требуется последующая задача;
- `runtime.*`: состояние слота изменилось, состояние задания изменилось, подготовка workspace завершилась или упала, очистка упала;
- `governance.*`: оценка риска запрошена или завершена, review signal записан, gate запрошен или решён, релизное решение принято, состояние release safety-loop изменилось;
- `fleet.*`: состояние сервера, Kubernetes-кластера, связности, health или placement scope изменилось;
- `interaction.*`: согласование запрошено, уведомление доставлено, обратный вызов получен;
- `billing.*`: запись затрат создана, распределение изменилось, черновик счёта обновлён.

## Что не считается доменом-владельцем

- Gateway-сервисы — пограничный слой, а не домен.
- `web-console` — интерфейс, а не домен.
- `platform-mcp-server` — MCP-инструментальная поверхность и политический шов, а не владелец бизнес-состояния. Его сервисный пакет документации живёт в `docs/domains/platform-mcp-server/**`, но это не добавляет новый домен-владелец в карту.
- `codex-hook-ingress` — входной контур нормализованных Codex hook events, а не владелец бизнес-состояния. Его сервисный пакет документации живёт в `docs/domains/codex-hook-ingress/**`, но это не добавляет новый домен-владелец в карту.
- `platform-event-log` — инфраструктурный контур общего журнала событий, а не бизнес-домен.
- `worker` — исполнитель фоновой работы, а не домен.
- `agent-runner` — исполнитель агентной сессии, а не домен.

## Апрув

- request_id: `owner-2026-04-26-platform-architecture-frame`
- Решение: approved
- Комментарий: доменная карта входит в сквозной архитектурный каркас платформы.
