8. Проекции

Модель одна. Аудиторий много. Платформенного инженера волнует топология сервисов; ревьюера по безопасности — какие сервисы касаются PCI-данных; продакт-менеджера — пользовательский поток. Всем им нужны разные диаграммы одной и той же базовой архитектуры.

Проекция — это сохранённая выборка: рецепт, который говорит что включать, как группировать, как раскладывать. Проекции никогда не изменяют модель; они только выбирают, как её показать.

view PaymentsLandscape {
    focus domain: Payments
    group by team
    layout elk
}

Три директивы проекции: сфокусироваться на модулях с domain: Payments, сгруппировать их по team, разложить алгоритмом ELK.

Зачем нужны проекции

Без проекций у вас одна диаграмма: каждый модуль, каждый интерфейс, каждая стрелка процесса — всё сразу. Для всего, что больше крошечной системы, такая диаграмма нечитаема.

Проекции позволяют срезать:

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

Каждая проекция — это сохранённый запрос. Получатели открывают тот же URL проекции и видят ту же диаграмму.

Директивы

В теле проекции используется небольшой набор директив:

Директива	Эффект
focus <label>: <value>	Включить только узлы, несущие эту метку. Несколько строк focus комбинируются.
group by <label>	Сгруппировать включённые узлы в кластеры по значению этой метки.
layout <algorithm>	Выбрать движок раскладки: elk, dagre, force или manual.
include <pattern>, ...	Добавить узлы по шаблонам имён.
exclude <pattern>, ...	Убрать узлы по шаблонам имён.
"description"	Голая строка-описание самой проекции.

Шаблоны — в стиле глоба по квалифицированным именам модулей: Payments.*, *.Internal, acme.shared.*.

Разобранный пример:

view PaymentsDashboard {
    focus domain: Payments
    focus security.zone: PCI

    group by team
    layout elk

    include "Payments.*", "PaymentGateway.*"
    exclude "*.Internal"

    "Overview of payment-domain services in PCI scope."
}

Читается так: включить модули с метками domain: Payments и security.zone: PCI, плюс всё, что подходит под Payments.* или PaymentGateway.*, минус всё, что подходит под *.Internal; сгруппировать результат по команде; разложить через ELK.

Раскладки

С просмотрщиком поставляются четыре варианта раскладки:

• elk — иерархическая, ELK.js. Лучше всего для сервисных топологий; даёт диаграммы в виде деревьев.
• dagre — раскладка ориентированного графа. Компактная, хороша для проекций с большим количеством зависимостей.
• force — силовая. Полезна для исследования кластеров без навязывания иерархии.
• manual — позиции берутся из локальных переопределений проекции (см. ниже).

Выбор только презентационный. Переключение раскладок не меняет модель.

Ручные правки

Иногда движок раскладки ставит узел в неудачное место. Перетащите его в просмотрщике; позиция сохраняется как локальный сайдкар проекции, никогда — на самом модуле. Перезагрузите, переключите проекцию или передайте URL коллеге — сохранённые позиции путешествуют с проекцией, а не с канонической моделью. Другая проекция тех же модулей может использовать совершенно другую раскладку. У одного и того же модуля есть право выглядеть по-разному в разных проекциях.

Сериализованная форма этих переопределений — забота просмотрщика, а не часть грамматики языка: движок читает их, когда выбрано layout manual, и иначе игнорирует.

Планы возникают из меток

В Archlang нет встроенной «сетевой плоскости» или «плоскости безопасности». Плоскости возникают из того, как вы помечаете модули и на чём фокусируете проекцию.

// Network plane — group by network segment, ignore everything else.
view NetworkDiagram {
    group by network.segment
    layout dagre
}

// Business plane — group by business entity.
view BusinessDomains {
    group by business.entity
    layout elk
}

// Security plane — focus on PCI scope, group by security zone.
view PCIScope {
    focus security.zone: PCI
    group by security.zone
}

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

Чего проекции не могут

• Изменять модель. Добавление узла в проекцию не добавляет его в архитектуру. Проекции — только чтение канонического состояния.
• Определять новую структуру. Проекция не может сказать «нарисуй здесь синтетическое ребро». Если вам нужно ребро, объявите шаг процесса.
• Переиспользовать содержимое другой проекции. Каждая проекция самодостаточна. Никакого extends для проекций. (Если это станет реальной потребностью — это будущее дополнение.)

Стабильные идентификаторы

Проекции несут стабильные идентификаторы так же, как модули и процессы. Форматтер выдаёт #view42 при сохранении. Переименование проекции обнаруживается как переименование, а не удаление-плюс-добавление.

Итоги

• Проекция — сохранённая выборка из канонической модели.
• Директивы: focus, group by, layout, include, exclude, "description".
• Раскладки (elk, dagre, force, manual) — только презентация.
• Ручные позиции сохраняются на проекции, никогда — на модели.
• Плоскости (сетевая, безопасности, бизнес) возникают из меток плюс сфокусированных проекций, а не из отдельной онтологии.

Что дальше

Глава 9: Поля и метки → — слой значений, на котором работают метки и проекции.