У большинства больших систем со временем появляются две архитектуры. Первая нарисована в документации. Вторая действительно работает в production. В YETI³ мы решили связать их в один непрерывный Архитектурный путь.

Этот путь называется CALMF. А контролирует его Диспетчер YETI³.

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

CALMF: от проекта до конкретной функции

Название CALMF одновременно описывает структуру Архитектурного пути:

От общего

  • Contour — контур: local, dev, production.
  • Application — конкретное приложение.
  • Layer — слой архитектуры.

К действию

  • Module — функциональный модуль.
  • Function — конкретная функция системы.

Получается последовательность:

Contour → Application → Layer → Module → Function.

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

Зачем нужен Диспетчер

Сам Архитектурный путь отвечает на вопрос «где находится функция?»

Но для работающего проекта этого мало.

Нужно знать: вызывается ли она вообще? Кто ей пользуется? Как быстро она работает? Возникают ли ошибки? Есть ли автоматические тесты?

Это зона ответственности Диспетчера.

CALMF формирует Архитектурный путь. Диспетчер контролирует происходящее на этом пути.

Архитектура получает востребованность

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

Диспетчер меняет эту картину.

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

Какие функции действительно нужны? Что используется постоянно? На какую возможность были потрачены ресурсы, но аудитория её практически не заметила?

Архитектура получает бизнес-контекст

Можно оценивать не только сложность разработанной системы, но и фактическую востребованность её частей.

А кто этим пользуется?

Количество вызовов — ещё не вся картина.

Функцией могут пользоваться гости, авторизованные клиенты, администраторы или автоматические процессы. Для бизнеса это совершенно разные сценарии.

Поэтому Диспетчер позволяет рассматривать Архитектурный путь через аудитории.

Разработчик видит работу функции. Product manager — её востребованность. Системный аналитик — реальные связи. Бизнес-аналитик — участие функции в процессах и аудиториях.

У производительности появляется адрес

«Сайт тормозит» — плохой диагноз.

Гораздо полезнее понимать, какая конкретно часть архитектуры создаёт задержку.

Диспетчер позволяет двигаться по Архитектурному пути до функции и контролировать время её выполнения.

Тот же принцип работает с ошибками. Вместо абстрактного события появляется архитектурный контекст: контур, приложение, слой, модуль и функция.

Чем точнее архитектурный адрес проблемы, тем короче путь от её обнаружения до исправления.

Автотесты становятся частью архитектуры

Для важной функции недостаточно знать, что ею активно пользуются.

Нужно понимать, защищена ли она автоматическими проверками.

В YETI³ автотесты связываются с функциональностью Архитектурного пути. Поэтому особенно важные зоны становятся заметны сразу.

Часто используется + проверяется

Важная функция находится под автоматическим контролем.

Часто используется + тестов нет

Это уже видимый риск для работающего бизнеса.

Зачем Диспетчеру WebGL

Тысячи функций, связей, вызовов и тестов можно разместить в таблицах.

Но большая архитектура по своей природе пространственна: у неё есть уровни, группы, зависимости и связи.

Поэтому Диспетчер использует WebGL-карту.

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

WebGL здесь не украшение админки. Это рабочий интерфейс навигации по Архитектурному пути.

Кому это нужно

Технической команде

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

Продукту и бизнесу

Product manager, системный и бизнес-аналитик получают данные о востребованности функций, аудиториях, связях и рисках.

А владелец бизнеса получает возможность задать очень простой вопрос:

что из того, что мы разработали и продолжаем оплачивать, действительно работает на наш бизнес?

Архитектура должна жить вместе с системой

Проект меняется каждый день. Поэтому CALMF не должен становиться ещё одним справочником, который постепенно устаревает.

Архитектурный путь развивается вместе с системой. Новые элементы включаются в модель, получают контекст и могут дополнительно обогащаться с помощью AI.

Но принцип остаётся неизменным:

Сначала реальная система. Затем её архитектурное описание. Не наоборот.
CALMF + Диспетчер
  • CALMF формирует Архитектурный путь;
  • каждая функция получает своё место в архитектуре;
  • Диспетчер контролирует реальную работу этого пути;
  • вызовы показывают востребованность;
  • аудитории дают бизнес-контекст;
  • скорость и ошибки получают архитектурный адрес;
  • автотесты показывают защищённость важных функций;
  • WebGL позволяет исследовать всё это как единую систему.

Архитектура перестаёт быть документацией

В конечном счёте идея CALMF очень проста.

Архитектура не должна существовать отдельно от работающего продукта.

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

Перед нами живая архитектура проекта.

CALMF показывает Архитектурный путь.
Диспетчер держит его под контролем.