Конституция и рантайм: как один монорепо держит 16 вертикальных SaaS без форков

Два репозитория, одна платформа

Монорепо, на котором живёт больше одного продукта, рано или поздно ловит один и тот же форк. Одной вертикали нужна лишняя колонка в Company, второй — обойти общий auth-флоу под SSO, третьей — собственный обработчик billing-вебхуков. Каждая начинает с патча общего кода. Каждая заканчивает вендоренной копией. Платформа теперь — это семь копий одной и той же штуки, расходящихся в стороны.

Разделение, которое это останавливает, старше монорепо как идеи. Развести контракт и реализацию. Контракт — это репозиторий inite-ecosystem: JSON Schema, capability YAML, манифест, валидатор. Реализация — inite-shared: 19 TypeScript-пакетов, настоящий Postgres, настоящий HTTP. Вертикали (rent, estate, shop, events, health, education, club и остальные из 16 в реестре) потребляют оба слоя.

Манифест репо-конституции короткий и несущий:

PR, добавляющий что-то из левой колонки, отклоняется на месте. Репо обслуживает спеку; спека обслуживает вертикали; вертикали ведут бизнес. Этот порядок — и есть вся архитектура.

Что именно контрактирует контракт

Вертикаль объявляет соответствие одним YAML-манифестом. Форма небольшая:

ecosystem: "^0.1.0"
id: inite.rent
name: INITE Rent
version: 1.0.0
domain: car_rental
maturity: production

capabilities:
  - { id: inbox,   version: "^1.0.0" }
  - { id: billing, version: "^1.0.0" }

runtime_packages:
  - "@inite/auth"
  - "@inite/billing"

entities:
  - { id: vehicle }
  - { id: reservation }

Манифест связывает вертикаль тремя обязательствами. Ring 1 — пять обязательных сущностей (User, Company, UserCompanyRole, ApiKey, CompanyPermissionOverride) должны быть в её Prisma-схеме или объявлены как алиасы. Ring 2 — каждый capability в capabilities: обязывает реализовать полный набор сущностей, которых этот capability требует. Заявил inbox — поставляешь Conversation и Message в том виде, в котором их ждёт бандл. Не готов на обязательство — не имеешь права заявлять capability. Ring 3 — всё остальное (vehicle, reservation, listing, appointment) свободной формы. Спека не ограничивает ни форму, ни именование, ни семантику.

Инструмент conformance проходит по манифесту и Prisma-схеме и выдаёт отчёт present/partial/missing по каждой сущности. Drift всплывает как статус в реестре, а не как тихий форк.

Что это даёт операционно

Три свойства появляются только после того, как разделение действительно сделано.

Первое — обновление рантайма развязано с изменением контракта. Фикс в @inite/auth — это runtime-patch. Он уезжает в каждую вертикаль, которая тянет пакет, в её собственном темпе. Спека не двигается. Миграции по 16 продуктам нет. Записи в CHANGELOG конституции тоже нет.

Второе — ломающие изменения имеют ровно одну вынужденную поверхность. Удаление поля из Company — это MAJOR-бамп спеки. Миграция уезжает в репо спеки папкой fixtures/migrations/<from>-to-<to>/ с до-и-после манифестами по каждой задетой вертикали, письменным walkthrough и deprecation window не короче одного MINOR до момента, когда старая схема перестанет валидироваться. Вертикали сидят на предыдущем MINOR ровно столько, сколько нужно: правило caret для нулевого major трактует ^0.1.0 как ~0.1.0, и манифест не уплывает в ломающее автоматически. Нужно опт-иниться руками.

Третье — реестр становится источником правды о здоровье платформы. На версии 0.2.0-rc.4 реестр отслеживает 18 вертикалей в семи статусных корзинах:

Эта таблица обновляется на каждом релизе спеки. Вертикаль, ушедшая в drift за пределы согласованного окна, всплывает в том же ревью. Capability, не доехавший до прода в течение двух релизов, идёт на пересмотр. Реестр — это и есть дашборд.

Почему рантайм ничем не владеет в спеке

Пакеты рантайма заявляют contract_version в registry/capabilities.yaml. Восемь из девятнадцати — на 1.0.0: контракт стабилен, ломающие требуют runtime MAJOR. Остальные одиннадцать сидят на 0.1.0 — бандлы вроде @inite/accounting и @inite/inbox-ui, где контракт ещё не несущий. Спека не пришпиливает версии рантайма. Она ссылается только на контракты пакетов. Capability-бандл может сказать @inite/inbox >= 0.5.0, но никогда == 1.0.3.

Обратное направление асимметрично — намеренно. Рантайм не имеет права отгрузить изменение контракта; это может только спека. Рантайм может отгрузить реализацию контракта под текущую спеку, и эта реализация двигается по своей версионной оси. Когда спека хочет убрать поле из Company, едет MAJOR спеки, рантайм подтягивается, вертикали мигрируют в своём темпе внутри deprecation window.

Работает это потому, что в репо спеки нет ничего исполняемого, что можно было бы сломать. Нет сервиса, который надо обновить. Нет базы, которую надо мигрировать. Нет поведения, которое надо тестировать. В репо — JSON Schema, capability YAML, примеры, валидатор. PATCH спеки — это правка документации. MINOR — новое опциональное поле в сущности или новый capability-бандл. MAJOR — единственное место, где ломающие изменения вообще пишутся: явно, с примерами, с deprecation window.

Как это выглядит на живых вертикалях

inite.rent живёт на Ring 1 плюс inbox, billing, incidents и notifications, Ring 3 — около двадцати доменных сущностей (Vehicle, Reservation, RentalContract, InsurancePolicy, MaintenanceRecord и так далее). Заявляет maturity: production, и на сегодня это единственная вертикаль с этим статусом.

inite.estate живёт на той же Ring 1, том же inbox и другой Ring 3 — Property, Listing, Deal, Showing, Offer. inbox ведёт себя идентично в обеих, потому что они реализуют один контракт; витрина и поиск расходятся, потому что Ring 3 свободен.

inite.shop тащит сильнее всех на storefront и billing — здесь сидит интеграция с agentic commerce. Ring 3 — Product, Variant, Order, Cart, Customer (алиас от User через aliases: в манифесте). То, что Customer локально называется иначе, записано в манифесте — этого достаточно, чтобы inite-conform подтвердил наличие Ring 1 даже с алиасом.

Три разные вертикали. Одна спека. Те же пять сущностей Ring 1 под локальными именами. Тот же capability inbox, поставляющий те же conversation-примитивы. Три разные Ring 3, которых спека не видит и видеть не должна. Детальный кейс по rent — в материале «Как мы за 4 недели перенесли CRM проката авто».

Когда это неправильная форма

Разделение «конституция vs рантайм» — неправильная форма в двух случаях. Первый — один продукт, который никогда не станет ничем большим. Добавлять репо спеки, реестр и conformance-инструмент к однопродуктовой компании — это оверхед без выгоды. Общий монорепо в самый раз. Второй — портфель продуктов, у которых на уровне данных нет ничего общего. Если продукт A — однопользовательская iOS-игра, а продукт B — B2B-платформа для закупок, общая сущность Company не даёт того рычага, на который похожа. Разделение окупается там, где есть реальный, повторяющийся контракт — мультитенантный SaaS с общей identity, биллингом, разговорами и нотификациями — на продуктах, которые выглядят по-разному снаружи и одинаково внутри.

У Inite 16 продуктов делят Ring 1, восемь стабильных Ring 2 capability и общий набор горизонтальных сервисов. Разделение окупается многократно. Без него каждая вертикаль за квартал получила бы свой форк @inite/auth. С ним реестр отслеживает честный drift, спека двигается в своём темпе, рантайм отгружает фиксы во все продукты сразу. Шире про тезис «один движок, много обличий» — в материале «Один движок, много обличий», а про операционную модель — «Inite operating model».

Два репозитория. 16 продуктов. Один контракт, которому разрешено меняться сознательно, и рантайм, которому разрешено меняться непрерывно. Это и есть весь паттерн.