# Исполнительный контекст

## Что не нравится в текущем состоянии

Текущий Control Plane является композиционным центром почти всей платформы. В одном процессе сосредоточены:
- gRPC API;
- HTTP endpoints;
- фоновые циклы и reconciler'ы;
- Kubernetes, GitHub, Registry и Postgres admin clients;
- домены пользователей, проектов, репозиториев, токенов, MCP, runtime deploy, interactions, mission control, governance и других подсистем.

Из-за этого проект уже выглядит как монолит внутри микросервисной оболочки:
- непонятно, где проходит граница домена;
- ownership размыт;
- изменение одного сценария тянет за собой unrelated код;
- shared DB усиливает скрытую связность;
- gRPC контракт слишком широкий и превращается в "god API".

## Что считаем корневой проблемой

Корневая проблема не в том, что у нас "мало сервисов". Корневая проблема в том, что сейчас смешаны четыре вещи:
- композиционный корень;
- бизнес-инварианты доменов;
- владение данными;
- operational логика длительных процессов.

Пока это живет вместе, код сложно читать, поддерживать и делегировать по владельцам.

## Что нужно получить в итоге

Нужна не максимальная дробность, а понятная декомпозиция. Целевое состояние:
- ограниченное число bounded contexts;
- отдельный gRPC контракт на сервис;
- своя база данных на сервис;
- отсутствие прямого SQL доступа к чужим данным;
- короткие и понятные composition roots;
- явные владельцы доменов и документации.

## Как идти быстро без unsafe breaking

Платформа уже развёрнута в live-кластере, поэтому миграции, `proto`, OpenAPI/AsyncAPI,
env/secrets/config и deploy path нельзя менять как одноразовый reset состояния.

Критически важное преимущество программы остаётся в другом:
- устаревшую control-plane-модель не нужно сохранять как самостоятельный продуктовый слой;
- старые `proto`, таблицы и call graph можно вычищать, но только после staged cutover без live rolling gap;
- layout репозитория и границы сервисов можно менять быстро, если потребители, миграции, секреты и deploy path обновляются согласованной последовательностью.

Это значит, что стратегия должна быть не "бережно обрастить монолит фасадами", а "быстро резать по доменам и удалять legacy-код кусками" через безопасный путь `expand -> migrate -> contract`.

## Принцип выбора доменов

Домен выделяется в отдельный сервис, если у него есть одновременно:
- собственные бизнес-инварианты;
- собственный набор таблиц или state machine;
- собственный operational профиль;
- понятный список потребителей;
- возможность назначить владельца команды.

## Минимизация распыления

Чтобы не раздробить систему сверх меры, не нужно делать по сервису на каждую таблицу. Нужны несколько достаточно крупных сервисов, каждый из которых соответствует bounded context и может жить автономно.

В этом пакете предлагается целевая модель из 6 сервисов, а не из 12-15 мелких процессов.
