В большой компании иногда легко заметить странный разрыв.

Разработчик меняет типизированный код, запускает тесты, проходит ревью и выкатывает результат через автоматизированный конвейер. Админ описывает желаемое состояние, а Kubernetes пытается привести к нему состояние фактическое.

А потом начинается архитектура. Открывается draw.io. Кто-то двигает прямоугольник на восемь пикселей вправо, экспортирует PNG, вставляет его в Confluence и кидает ссылку в чат. Через месяц сервис переименовали, интеграцию переделали, команда-владелец сменилась, а прямоугольник продолжает жить своей жизнью.

Архитекторы обычно не любят выражение “рисователь квадратов”. Понимаю почему. Работа архитектора явно сложнее рисования схем. Но само выражение тоже возникло не на пустом месте.

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

Диаграмма должна быть представлением модели. У нас слишком часто моделью считается сама диаграмма.

Машина понимает код, но не понимает стрелку

Современная инженерия в основном работает с намерением, выраженным в форме, которую может разобрать машина.

В Kubernetes объект хранит желаемое состояние в spec, наблюдаемое попадает в status, а управляющий контур пытается уменьшить разницу между ними. Официальная документация называет такой объект “записью намерения”. В разработке ту же роль играют типы, интерфейсы, тесты и статический анализ. В данных есть схемы, миграции и контракты.

В архитектуре намерение часто остаётся подписью рядом со стрелкой. Ни одна система не знает, что означает “использует”, кто отвечает за эту связь, допустима ли она, относится ли она к production и что должно произойти после согласования.

У прямоугольника нет устойчивой идентичности. Если Payments API нарисован на семи схемах, это не один объект в семи представлениях. Это семь отдельных фигур с похожим текстом. Переименование означает ручной обход документов, если кто-то вообще вспомнит это сделать.

Со стрелками ещё веселее. Одна и та же линия может означать HTTP-запрос, передачу файла, поток данных, доверие, организационную зависимость или просто “эти штуки как-то связаны”. Выглядят стрелки одинаково. Последствия у них совершенно разные.

Поэтому на обычной схеме трудно надёжно ответить даже на довольно приземлённые вопросы:

• кто зависит от этого API;

• у каких production-сервисов нет владельца;

• какие системы доступны из интернета вопреки политике;

• что изменилось в архитектуре между двумя ревью;

• расходится ли согласованное решение с тем, что работает сейчас.

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

Схема 1. Картинка не создаёт проблему сама по себе. Она просто не умеет поддерживать идентичность объектов, типы связей, историю и сверку с production.

Самый неприятный разрыв находится в конце процесса. Production меняется постоянно, а архитектурные документы обновляются эпизодически. Команда либо бесконечно догоняет реальность, либо перестаёт верить схемам. Обычно происходит и то и другое.

Почему всё сложилось именно так

Можно сказать, что архитекторы просто не умеют программировать. Звучит бодро, но объясняет мало. Многие архитекторы выросли из сильных инженеров. Причины, как обычно, менее эффектные.

Именно поэтому к профессии возникает дополнительный вопрос. Архитекторы обычно понимают, что одному интерфейсу недостаточно. За удобным инструментом должны стоять модель, хранилище, API, процесс изменений и обратная связь от работающих систем. Так устроены инструменты, которыми они пользовались как разработчики, админы или безопасники.

Но после перехода в архитектуру бывший инженер иногда принимает холст без памяти как основной рабочий объект. Как будто вместе с новой должностью можно забыть про идентичность, версии, проверки и автоматизацию. В худшем случае роль сводится к draw.io-инженеру: согласовал PNG и пошёл на следующий комитет.

Конечно, архитектор редко может в одиночку построить новую платформу и переписать корпоративный процесс. Ему могут не дать команду, бюджет или право менять stage gate. Тем не менее результат выглядит странно: инженерная роль десятилетиями обслуживает один из самых ручных процессов в компании.

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

Во-вторых, не каждое архитектурное решение исполняемо. Архитектура состоит не только из ресурсов и связей. В ней есть гипотезы, ограничения, компромиссы и договорённости между командами. Нельзя нажать apply и автоматически получить хорошую границу домена или новую ответственность команды. Но из этого почему-то делают вывод, что структурировать нельзя вообще ничего.

В-третьих, строгие нотации часто требовали слишком много дисциплины до того, как начинали приносить пользу. UML, ArchiMate и корпоративные репозитории моделей пытались дать семантику, а команды в ответ уходили к понятным квадратам и линиям. C4 появился как более простой общий язык с несколькими уровнями абстракции. Это помогло. Однако C4, нарисованный как пачка независимых картинок, всё равно остаётся пачкой независимых картинок.

Sparx Enterprise Architect показывает обе стороны этой истории. Это полноценный инструмент моделирования с UML, SysML, ArchiMate, общими репозиториями, аудитом и синхронизацией кода. Но лицензия стоит от 245 до 965 долларов в зависимости от редакции, а интеграционный сценарий требует Pro Cloud Server, подходящую редакцию клиента, сетевой доступ и учётные данные. В итоге компания платит за модель, а затем открывает отдельный проект по интеграции модели.

Сам ArchiMate формально жив: текущая спецификация имеет версию 3.2, существуют сертификация и формат обмена между инструментами. Но стандартный словарь ещё не создаёт рабочий контур. Семантически правильная схема может так же лежать отдельно от Jira, Git и production. Главный вопрос не в том, правильно ли названа стрелка, а в том, вызывает ли изменение модели хоть какое-то действие за пределами репозитория моделей.

Наконец, сам процесс обычно вознаграждает не актуальность, а согласование. Артефакт нужен к комитету во вторник. Комитет прошёл, галочка поставлена, работа считается законченной. Никто не отвечает за автоматическую сверку решения с реализацией через полгода. В такой системе даже хороший архитектор будет производить документы, потому что именно документы проходят stage gate.

Белую доску при этом никто не отменял. Во время разговора свободное рисование часто быстрее любой модели. Ошибка начинается позже, когда временный набросок без разбора назначают долговечным реестром архитектуры.

Кажется, нужные детали уже изобрели

Новая великая нотация нам, скорее всего, не нужна. Короче: Я ВОР. Я ВОРОВАЛ. Почти все детали решения давно работают в соседних областях.

У CMDB и software catalog есть инвентарь, владельцы и жизненный цикл. У Kubernetes API есть версионируемые типы, устойчивые идентификаторы, spec/status, валидация и расширяемость. C4 и инструменты вроде IcePanel умеют отделять модель от конкретного представления. Git и CI дают diff, ревью, политики и воспроизводимую историю. Контроллеры и интеграции умеют сопоставлять желаемое состояние с наблюдаемым.

Infrahub уже собирает многие из этих идей для инфраструктурных данных: расширяемую схему, граф, версии данных, ветки, diff, peer review, CI, API, UI и генераторы. После него трудно говорить, что такого подхода вообще не бывает.

Вокруг Infrahub встречается число 10000, которое легко принять за предел модели. В документации по производительности это размер страницы запроса, а не ограничение количества объектов. Сама OpsMill пишет о production-инсталляциях с сотнями тысяч управляемых объектов на одном экземпляре. Это заявление поставщика, поэтому конкретной компании всё равно придётся проверять собственные запросы, ветки и нагрузку. Но ограничение в десять тысяч объектов здесь было бы неверным аргументом.

Infrahub пока сосредоточен прежде всего на инфраструктурных и сетевых данных. Общая архитектурная модель должна дополнительно связать приложения, домены, команды, API, решения и риски. Но фундамент уже можно пощупать. Это не фантазия про очередной портал.

Остаётся собрать это вокруг другого рабочего объекта.

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

apiVersion: architecture.company/v1
kind: Component
metadata:
  name: payments-api
  uid: component:payments-api
spec:
  owner: team:payments
  domain: commerce
  lifecycle: production
  provides:
    - api:payments-v2
  dependsOn:
    - resource:ledger-db
  desiredState:
    internetExposure: false
status:
  discoveredFrom:
    - git: payments/api
    - runtime: prod-eu-1
  observedState:
    internetExposure: true
  drift:
    - policy: no-public-payments-api

Нет, я не предлагаю запихнуть всю архитектуру в YAML и заставить аналитиков писать манифесты. Перед моделью может стоять привычный визуальный редактор. Могут быть формы, импорт из CMDB, обнаружение объектов в облаке и нормальный API. Важно другое: под всеми интерфейсами должен оставаться единый контракт.

Схема 2. Это не одна гигантская CMDB и не буквальный “Kubernetes для архитекторов”. Источники сохраняют происхождение данных, а общий API даёт объектам идентичность, типы, проверки и разные представления.

Ну сделайте хотя бы рисовалку над Kubernetes

Полная архитектурная платформа может показаться слишком большим проектом. Но для начала можно взять гораздо более узкий срез.

Во многих компаниях значительная часть прикладного runtime уже описана объектами Kubernetes. Deployment, StatefulSet, Service, Ingress или Gateway, ConfigMap, Secret, политики и собственные CRD существуют в желаемом и фактическом состоянии. У них есть API, версии, статусы, события и контроллеры. Хранилище и процесс применения уже работают.

Из манифестов и состояния кластера можно собрать типизированный граф. Часть связей видна через ownerReferences, selectors и правила маршрутизации. Неизвестные зависимости можно подтянуть из software catalog или попросить владельца указать явно.

Дальше нужен визуальный слой. На схеме видны workload, Service, Gateway, namespace, владелец, политики и найденный дрейф. Изменение в редакторе создаёт patch или pull request, а не новый PNG. После применения фактический статус возвращается в ту же модель. Граф есть, диаграммы есть, diff есть. Уже неплохо.

Kubernetes не описывает всю компанию. Управляемые базы, SaaS, legacy, облачные ресурсы и организационные решения останутся снаружи. Зато получится честный вертикальный срез, на котором можно проверить полный цикл от намерения до наблюдаемого состояния.

Для облачной инфраструктуры похожий подход уже существует. ArchFormation позволяет визуально собирать AWS и Kubernetes-компоненты и генерировать Terraform в GitHub. Brainboard работает с несколькими облаками, генерирует Terraform или OpenTofu, импортирует существующую инфраструктуру, запускает plan/apply и ищет drift. Brainboard публиковал обновления в 2026 году, поэтому называть оба проекта заброшенными было бы безосновательно.

Эти продукты доказывают, что инфраструктуру уже можно одновременно рисовать, превращать в код и сверять с фактом. При этом модель приложений, доменов, API, команд и архитектурных решений часто продолжает жить отдельно в Confluence. Инфраструктурный контур получился живым, архитектурный остался документным.

Проверка квадратом

Есть простой вопрос, который отделяет рисовалку от инженерного инструмента: что происходит после того, как я добавил на схему новый API Gateway?

Если появился только ещё один квадрат, перед нами рисовалка. Если система создала или хотя бы предложила объект с идентификатором и владельцем, типизированные связи, проверки обязательных полей, архитектурный diff и следующие действия, это уже похоже на инженерный процесс.

Причём следующий шаг не обязан сразу создавать production-ресурс. Для опасных изменений совершенно нормален режим предложения. Платформа готовит патч, план или заявку, человек проверяет и подтверждает. Исполняемость здесь означает не “робот делает всё”, а “структура решения не теряется по дороге к реализации”.

И после реализации работа не заканчивается.

Схема 3. В центре находится накопленное состояние: объекты, владельцы, решения, свидетельства и история. Наблюдение за фактом возвращает процесс к новому намерению.

Обычный архитектурный процесс заканчивается словом “согласовано”. В живой модели согласование находится где-то посередине. Затем изменение нужно реализовать, сравнить с фактическим состоянием, найти дрейф и вернуть этот факт в следующий цикл решения.

Архитектор никуда не исчезает

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

Кому-то всё равно нужно определять язык модели: какие объекты существуют, что значат связи, где проходят границы, каким данным можно доверять. Кто-то должен формулировать инварианты, разбирать исключения, связывать техническое изменение с риском и следить, чтобы разные представления не противоречили друг другу. Это и есть работа архитектора.

Она становится даже более инженерной. Вместо ручного обслуживания картинок появляются вопросы посложнее:

• как спроектировать минимальную онтологию и не вырастить монстра;

• где проходит граница между declared, desired и observed state;

• какой источник авторитетен для конкретного поля;

• какие правила можно проверять автоматически и как оформлять исключения;

• как показать одну модель разным аудиториям, не смешав уровни.

Где комбайн мечты может сломаться

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

Самая частая иллюзия называется “единый источник истины”. В реальности Git может быть авторитетен для владельца API, облако для фактического endpoint, HR-система для состава команды, а архитектурное решение для допустимости зависимости. Нужен не один источник на всё, а понятная политика происхождения данных для каждого поля.

Автоматический импорт легко закрепляет некачественные данные. Если без разбора перенести старую CMDB, модель быстро наполнится устаревшими объектами без владельцев и понятного назначения. Обнаруженный объект должен хранить происхождение, статус и потребность в разборе. Сам факт обнаружения ещё не делает его достоверным архитектурным знанием.

Ещё одна ловушка состоит в желании заранее описать вообще всё: домены, процессы, данные, инфраструктуру, риски и оргструктуру. Такая универсальная метамодель способна съесть продукт раньше первого полезного релиза. Начинать лучше с нескольких объектов и вопросов, которые уже болят.

Исполняемость тоже должна быть выборочной. Отсутствие владельца можно проверить автоматически. Заявку на firewall можно подготовить автоматически. Переразбить домены и перевести команды автоматически нельзя. Инструмент должен различать подсказку, проверку, план и действие.

И последнее: удобство рисования нельзя выбрасывать. Если для добавления квадрата нужно сначала изучить внутренний DSL, люди останутся в старом инструменте. Нормальный интерфейс позволяет сначала думать визуально, а потом мягко превращает набросок в объекты, связи и список незаполненных полей.

Как начать и не открыть пятилетнюю программу трансформации

Здесь обычно появляется аккуратный список: выберите пилот, опишите шесть сущностей, подключите два источника, посчитайте метрики. Советы разумные, но архитекторов вряд ли нужно ещё раз учить не запускать пятилетнюю трансформацию в первый понедельник квартала.

Интереснее другой вопрос: из каких деталей собрать саму систему?

Возьмите существующую CMDB или каталог как один из источников данных, а не как священную таблицу со всей истиной. Поставьте перед источниками API server, который выдаёт объектам устойчивую идентичность, тип, схему, версию и правила проверки. Храните авторитетное состояние и историю изменений в нормальной базе. Отношения проецируйте в граф. Над графом сделайте интерфейс, где один и тот же объект можно увидеть в каталоге, на диаграмме, в impact analysis и в форме изменения.

Дальше нужны уже знакомые инженерные механизмы: reviewed diff вместо пересылки новой картинки, desired и observed state вместо ручного опроса владельцев, контроллеры и импортеры вместо копирования данных, Git и CI там, где они действительно удобны. CMDB, API server, база, граф и рисовалка по отдельности проблему не решают. Смысл появляется, когда они образуют один контур.

Это не план внедрения. Это конструкция продукта.

Я как раз такую систему и пишу

На этом месте можно было бы закончить красивой схемой. Но описанный выше контур я уже собираю в проекте. Сейчас это работающий прототип schema-driven control plane, на котором можно проверить идею не только в тексте.

Definition как контракт типа

Новый тип объекта начинается с ResourceDefinition. В нём задаются API group и version, kind, plural, scope, JSON Schema, поля для поиска, связи, capabilities, контроллеры и политика изменений. После регистрации definition тип появляется в discovery, API, интерфейсе и MCP-инструментах. Для него не нужно отдельно писать таблицу, CRUD и собственную страницу.

В редакторе есть обычная форма, YAML и JSON. Это три представления одного definition, а не три независимые конфигурации. У поля можно сразу указать обязательность и участие в поиске. Существующие поля защищены проверкой совместимости: например, нельзя незаметно удалить поле, поменять его тип или сделать уже сохранённые объекты невалидными.

В definition компонента восемь полей. Для owner одновременно заданы тип, обязательность, поиск и описание.

Ссылки тоже являются частью схемы. Ниже moduleRef объявлен как обязательная связь part-of с одним Module, а componentRefs как необязательная связь depend-on со многими Component. API проверяет эти ссылки, а граф строит только типизированные рёбра, прошедшие валидацию.

Кардинальность, JSON Pointer, целевой тип и обязательность задаются там же, где схема ресурса.

В том же контракте включаются полнотекстовый поиск и графовая проекция, выбираются runtime-валидатор и контроллер, задаётся review policy. В примере изменение компонента требует одного согласования, а автор не может согласовать собственную ревизию.

Definition отвечает не только за форму данных, но и за поведение типа в системе.

Если нужна точная схема, её можно читать и редактировать как JSON Schema Draft 2020-12. Визуальный редактор покрывает частые структурные поля, а YAML и JSON сохраняют более сложные конструкции.

Одна и та же схема используется при вводе данных, в API и при серверной валидации.

Например, у WorkloadDeployment связи instance-of, uses-artifact, deployed-to, scheduled-to и depends-on объявлены в definition и проверяются как часть ресурса. Это уже не подписи на стрелках, а контракт модели.

UI читает ту же декларацию связей, которой пользуются API и графовая проекция.

Объект вместо квадрата

После появления definition создаются обычные ресурсы. У каждого есть устойчивая идентичность, версия, labels, annotations, desired generation и observed generation. На обзорной странице сразу видно, какой объект открыт и успела ли система обработать его текущее намерение.

У checkout-api desired и observed generation совпадают, а состояние ресурса — Ready.

Содержимое разделено на spec и status. В spec находится желаемое состояние, которым управляет пользователь или интеграция. В примере это владелец, runtime, репозиторий, тип компонента и ссылка на модуль. status принадлежит контроллеру и содержит наблюдаемый результат. Для чисто архитектурного объекта он может быть пустым; для runtime-ресурса там появляются provider data и conditions.

Ссылка moduleRef раскрывается как структурированный объект, но остаётся той самой связью part-of, объявленной в definition.

Что происходит под капотом

Ядро не знает, что такое Component, VirtualMachine или Database. Для него любой объект является универсальным resource envelope, устроенным примерно так же, как объект Kubernetes:

apiVersion: group/version
kind: AnyRegisteredKind
metadata:
  uid: server-assigned
  name: resource-name
  labels: {}
  resourceVersion: "42"
  generation: 7
spec:
  # desired state конкретного типа
status:
  observedGeneration: 7
  conditions: []
  # observed state контроллера

Смысл spec определяет ResourceDefinition. Сам envelope, правила идентичности, версии, история операций и разделение desired/observed state остаются общими для всех типов. Поэтому добавление нового kind не требует менять ядро API server.

ResourceDefinition задаёт контракт, а доменная логика подключается через validation и controller workflows.

Все команды изменения проходят через Temporal. Read path намеренно устроен проще: чтение не превращается в workflow, потому что ему не нужны durable retry и длительная координация. Создание, обновление, удаление, применение согласованной ревизии и reconcile используют один общий путь:

1. UI, API, SDK, MCP или DSL отправляет тот же resource envelope.

2. API server проверяет route identity, authorization, resource version и загружает активный ResourceDefinition.

3. После синхронного admission сервер запускает конечный Temporal workflow. Идемпотентность, retry, timeout и история выполнения становятся частью команды, а не самодельным кодом каждого интегратора.

4. Workflow выполняет общие проверки схемы и связей. Если definition содержит validatorKey, он вызывает пользовательский validation flow. Такой flow может проверить доменное правило или обратиться к внешнему API.

5. Принятое desired state и объект Operation записываются одной транзакцией в PostgreSQL. Это авторитетное состояние системы.

6. Если указан controllerKey, Temporal запускает create, update, delete или reconcile flow. Контроллер обращается к Kubernetes, облаку, CMDB или другому внешнему провайдеру и возвращает наблюдаемый результат в status и observedGeneration.

7. Отдельные workers обновляют Neo4j, OpenSearch и SpiceDB. Эти хранилища можно перестроить из PostgreSQL: Neo4j отвечает за граф, OpenSearch за полнотекстовый поиск, SpiceDB за ReBAC-проекцию прав.

Команда проходит через API server и Temporal. PostgreSQL хранит ресурсы, ревизии и операции; остальные хранилища являются read-проекциями.

На схеме показан конвенциональный deployment profile: PostgreSQL, OpenSearch, Neo4j и SpiceDB. Контракт ресурса от конкретных адаптеров не зависит, но такой набор проще обсуждать и эксплуатировать в обычной платформенной команде.

Расширяемость: тот же operator pattern

Здесь аналогия с Kubernetes уже не декоративная. ResourceDefinition играет роль CRD, resource envelope соответствует custom resource, а controller workflow выполняет работу оператора.

Расширение состоит из двух частей. Definition описывает данные и выбирает расширения по ключам. Каталог runtime-компонентов связывает эти ключи с конкретными workflows и activities. Эти flows не прибиты к одной кнопке UI: control plane может вызвать их при admission, явной операции или повторном reconcile, а один workflow может запустить другой как child workflow. Для одного kind достаточно только схемы и поиска. Другому можно подключить проверку внешней политики. Третьему нужен полноценный controller, который создаёт реальный ресурс, следит за ним и возвращает status.

Общий контур при этом не переписывается. Идентичность, версии, authorization, review, idempotency, история, операции, проекции и UI уже существуют. Разработчик расширения добавляет доменное поведение. Примерно ту же границу проводит Kubernetes: API server обслуживает custom resource, а operator знает, как превратить его spec в работающий объект.

Так продукт перестаёт быть CMDB с диаграммой. CMDB умеет хранить запись. Control plane принимает намерение, проверяет его, исполняет через подключаемый controller, наблюдает результат и пытается сблизить spec со status.

Одна модель, несколько способов чтения

У объекта есть собственный граф окружения. Можно менять глубину, направление и тип узлов, не создавая ещё одну диаграмму. На примере checkout-api видны модуль, worker, архитектурные flows и артефакт. Всего в выбранном окружении 18 узлов и 32 связи.

Это запрос к общей модели вокруг конкретного UID, а не сохранённая копия canvas.

Из тех же объектов строится архитектурный workspace. Уровень абстракции и вложенность задаются метаданными definitions, поэтому System, Module и Component не приходится заново рисовать для каждого представления.

Один фрагмент общей модели: retail-platform → checkout → два компонента. В canvas нет отдельной копии этих объектов.

InteractionFlow тоже является обычным ресурсом. Один flow можно показать поверх графа или развернуть в sequence-представление с вложенными вызовами и параллельными ветками. Диаграмма остаётся удобным способом чтения, но перестаёт быть местом хранения смысла.

Один и тот же flow можно читать как наложение на архитектурный граф или как последовательность шагов.

Есть и связка с runtime-слоем. На графе ниже WorkloadDeployment связан с сервисом, артефактом, кластером, node group и архитектурным компонентом. Так из вопроса «где это нарисовано?» получается вопрос «какие объекты и зависимости затронет изменение?».

Ближайшее окружение workload строится из типизированных ссылок ресурсов, а не из отдельно поддерживаемой картинки.

Change request: ревью меняет объект, а не картинку

Если definition требует согласования, прямое обновление ресурса не проходит в обход процесса. Вместо него создаётся change request. На странице объекта видна отдельная история открытых и завершённых веток изменения.

Для ресурса открыт change request на обновление. Здесь же видны состояние, автор, head и число согласований.

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

Сервер уже проверил revision, а интерфейс показывает, что требуется одно согласование и self-approval запрещён.

Diff тоже считает сервер. В примере меняются два поля: описание и отображаемое имя checkout-api. Ревьюер видит JSON Pointer каждого изменения и точные старое и новое значения.

Ревью относится к revision 1 и её content hash. Новая ревизия потребует нового решения.

Change set: один манифест на связанное изменение

Один change request соответствует одному ресурсу. Когда изменение затрагивает несколько объектов, нужен change set: ветка из 1–100 resource envelopes с общим манифестом. Валидация сначала собирает предлагаемый мир целиком и только потом проверяет ссылки, поэтому порядок элементов не влияет на результат. Ресурс может ссылаться на другой ресурс, создаваемый в том же наборе.

Для статьи я подготовил отдельный демонстрационный change set из двух обновлений: checkout-api и checkout-worker. Он отправлен на ревью, но не применён к активной модели.

У набора есть собственные состояние, head revision, manifest hash и concurrency version.

Внутри ревизии перечислены обе операции, base generation и требуемая policy. Сам manifest неизменяем, а review привязан к паре revision + manifest hash. Если автор создаст новую ревизию, старые согласования перестанут действовать.

Два обновления рассматриваются как одно связанное предложение, а не как две несогласованные заявки.

Здесь важно не приукрашивать статус проекта: атомарное применение многообъектного change set пока не готово. Последовательный вызов нескольких API выглядел бы как merge, но не гарантировал бы атомарности. Поэтому действие применения закрыто, пока все desired-state intents и дочерние operations нельзя записать одной транзакцией.

Я не предлагаю копировать именно этот стек или объявлять мой продукт готовой заменой всему архитектурному хозяйству и срочно его купить. Для меня это способ проверить более важную гипотезу: знакомые инженерные детали действительно складываются в инструмент, где модель, процесс изменения и визуальное представление работают вместе.

Архитектура живёт в прошлом не потому, что люди рисуют квадраты. Квадраты тут ни при чём. Она живёт в прошлом, пока перемещение квадрата не меняет ничего, кроме картинки.

Когда за фигурой появляется объект, за стрелкой типизированная связь, за ревью проверяемый diff, а за решением наблюдение факта, архитектура наконец начинает вести себя как инженерная дисциплина.

Источники и продолжение

• Kubernetes: Objects in Kubernetes о модели spec/status и объекте как записи намерения.

• Kubernetes: Custom Resources и Operator pattern о сочетании расширяемого API, custom resources и контроллеров.

• Temporal Platform Documentation о durable execution и восстановлении workflow после сбоев.

• C4 model: Tooling о различии между diagramming и modelling, модели как графе и представлениях как его подмножествах.

• Backstage Software Catalog о централизованном каталоге владельцев и метаданных программных объектов.

• IcePanel: Model objects view об объектах модели, их типах, статусах, командах и использовании в диаграммах.

• Sparx Systems: Enterprise Architect pricing и руководство по интеграции.

• The Open Group: ArchiMate certification о версии 3.2 и экосистеме стандарта.

• Infrahub, настройка производительности и описание production-масштаба от OpsMill.

• ArchFormation и Brainboard как примеры визуального управления инфраструктурой с генерацией IaC.