# AfRel -- введение

**AfRel** -- архитектурная методика на основе ресурсных ограничений.

## Введение в AfRel (Architecture Framework with Resource Limitations)

## Проблема

Существующие подходы к управлению архитектурой (**Enterprise Architecture**, **TOGAF**, **ArchiMate**, **UML**, **SysML**) часто страдают от разрыва между «бумажной» архитектурой и материальной реальностью разработки, эксплуатации и бизнеса.

* Требования теряются в переходах между уровнями.
* Архитектурные решения принимаются без проверяемой связи с бизнес-целями.
* Деньги, время и усилия тратятся на «паразитические» задачи — те, которые не повышают способность системы выживать в меняющейся среде.
* Документация версионируется вручную, трассировка исчезает, ответственность размывается.

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

## Базовый императив

**AfRel** исходит из того, что любая система (бизнес, IT-сервис, код, команда) существует в условиях ограниченных ресурсов (время, деньги, люди, вычислительные мощности, энергия) и стремится реализовать базовый императив *выживай*.

В переводе на язык архитектуры это означает:

```text
Каждое архитектурное решение должно быть обосновано тем, как оно повышает шансы
системы сохранить своё существование или развиваться в данных условиях.
```

Если решение или задача не могут быть обоснованы в терминах выживания — они считаются паразитическими (эксплуататорскими, потребительскими) и подлежат исключению или пересмотру.

## Основные принципы AfRel

* *Материальность* — все артефакты (цели, требования, задачи, проверки) имеют измеримые атрибуты по трём осям: количество (X), качество (Y), деньги/ресурсы (Z).
* *Трассируемость* — каждый артефакт имеет явную ссылку на родительский артефакт (от бизнес-цели до проверки инфраструктуры).
* *Неизменность имени* — артефакты не переименовываются; при изменении создаётся новый артефакт, старый объявляется устаревшим (`deprecated`).
* *Четырёхчастная структура* — на каждом уровне (`бизнес`,     `архитектура`,     `софт`,     `инфра`) артефакты делятся на:
  + `targ` (цель, императив)
  + `req` (требование, условие)
  + `task` (задача, действие)
  + `check` (проверка верификации)
* *Версионирование* — сквозное, четырёхуровневое (x.y.z.b = бизнес.архитектура.софт.инфра), хранится в системе контроля версий (**Git**) в виде тегов, привязанных к артефактам.
* *Автоматизируемая проверка* — каждая `check` должна иметь измеримый критерий и, по возможности, автоматический способ верификации (`CI`, нагрузочные тесты, финансовая модель).

## Основные понятия

|  Понятие | Описание |
|---|---|
|Куб выживания| Пространство с осями X (количество), Y (качество), Z (деньги/ресурсы). Любое состояние системы — точка в кубе, любая цель — вектор (траектория) движения.|
|Артефакт     | Поименованный объект в репозитории, содержащий `targ` , `req` , `task` или `check` и обязательные поля X, Y, Z.|
|Уровень артефакта| `b` (business), `a` (architecture), `s` (software), `i` (infrastructure).|
|Часть артефакта| `targ` , `req` , `task` , `check` .|
|Иерархия имён| Строится добавлением цифр без разделителей (например, `1b-targ` → `1a1-req` → `1a1s1-task` ).|
|Репозиторий бизнес-процесса| Хранит артефакты уровня `b` и `a` .|
|Репозиторий софта/инфры| Хранит код, тесты, скрипты, но версии синхронизируются с бизнес-тегами.|

## Краткий обзор практик

* *Формулировка цели* — в терминах X, Y, Z с квадрантом куба выживания (расширение/сжатие, повышение/снижение качества, отток/приток ресурсов).
* *Контрольный вопрос* — «Как эта цель повышает выживание?» (ответ в котором нет измеримых параметров, времени и денег --  цель не принимается).
* *Разложение требований* — `цель` (`b-targ`) → `архитектурные требования` (`a-req`) → `задачи` (`a-task`,    `s-task`,    `i-task`) → `проверки` (`a-check`, ...).
* *Планирование* — дорожная карта, где бизнес-задачи (`b-task`) сопровождаются метками архитектурных задач (`a-task`) и контрольными точками.
* *Автоматическая проверка* — **CI** проверяет наличие обязательных полей, трассировку, неизменность имён, связь тегов с артефактами.

## Место **AfRel** среди других фреймворков

**AfRel** не заменяет **TOGAF**, **ArchiMate**, **UML**, **SysML** — он дополняет их, вводя дисциплину материальности и проверки. Вы можете использовать любые нотации для моделирования, но **AfRel** требует, чтобы каждый элемент модели был привязан к артефакту `req` , `task` или `check` с измеряемыми X, Y, Z.

Таким образом, **AfRel** — это методология поверх методологий или парадигма управления архитектурой, основанная на ресурсных ограничениях.

## Дальнейшие шаги

В последующих разделах документа будут детально описаны:

* Структура артефактов (YAML-схема)
* Кубы выживания и траектории
* Дорожная карта (графическая нотация)
* Версионирование и связи с Git
* Шаблоны чек-листов
* Примеры (правильные и антипаттерны)
* Рекомендации по внедрению