FASA: архитектура ПО без слоёв и адаптеров. Спецификация

1. Введение

1.1. Назначение

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

1.2. Философия архитектуры

• Плоскостность: Отказ от иерархических слоёв (presentation/domain/data, gateway, adapter и т.п.). Все компоненты находятся на одном уровне видимости в графе зависимостей.

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

• Контекстная адаптивность: Программный интерфейс не привязан к механизму вызова. Он может быть реализован как статический контракт, сетевой протокол, IPC-канал или соглашение обмена сообщениями в зависимости от среды исполнения.

• Строгая ацикличность: Все зависимости образуют направленный ациклический граф (DAG). Циклы запрещены на любом уровне.

2. Архитектурные сущности

Система FASA состоит исключительно из трёх типов сущностей:

3. Семантика и инфраструктура

3.1. Граница ответственности

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

3.2. Что относится к семантике (под контролем FASA)

• Объявление и использование SI, I, UI в исходном коде

• Направление зависимостей между модулями/пакетами/компонентами

• Сигнатуры методов, форматы сообщений, гарантии контрактов

• Версионирование интерфейсов и политика совместимости

• Логика обработки данных и управления потоком исполнения

3.3. Что относится к инфраструктуре (вне контроля FASA)

3.4. Критерий разделения

Компонент считается инфраструктурным (и допустимым), если выполняются оба условия:

1. Он не объявляет и не потребляет SI, определённые в рамках предметной области системы.

2. Его удаление или замена не требует изменения исходного кода I или SI (только конфигурации развёртывания).

4. Правила зависимостей и плоскостность

4.1. Допустимые зависимости

• I -> SI : Обязательная. Каждая реализация должна удовлетворять минимум одному программному интерфейсу.

• I -> I : Разрешена. Реализация может использовать другие реализации для делегирования или композиции.

• SI -> SI : Разрешена. Интерфейсы могут расширять или ссылаться на другие интерфейсы.

• UI -> SI / UI -> I : Разрешена. Пользовательский интерфейс подключается к системе через контракты или напрямую к реализациям.

4.2. Запрещённые зависимости

• SI -> I : Строго запрещено. Контракт не может знать о существовании конкретных реализаций.

• * -> UI : Запрещено. Ни один внутренний компонент не должен зависеть от пользовательского интерфейса.

• Циклы: Запрещены любые циклические зависимости (SI<->SI, I<->I, I<->SI и т.д.).

• Промежуточные компоненты: Запрещено создавать выделенные адаптеры, транспортеры, фасадные модули или шлюзы, единственная задача которых — преобразовывать или перенаправлять вызовы между I и SI.

4.3. Принцип плоскостности

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

5. Версионирование и политика совместимости

5.1. Схема версионирования

• Версионирование применяется только к SI.

• Используется стандарт SemVer (MAJOR.MINOR.PATCH).

• Версии I и UI управляются независимо и не обязаны синхронизироваться с SI.

5.2. Обратная совместимость (MINOR / PATCH)

Пока мажорная версия не изменена, любые обновления SI обязаны сохранять полную обратную совместимость:

• + Добавление новых операций, полей, сообщений или опциональных параметров

• + Исправление ошибок, не меняющее семантику контракта

• — Удаление, переименование или изменение порядка существующих элементов

• — Ужесточение требований к валидации, типам или состоянию

5.3. Мажорные обновления и правило двойной поддержки

При публикации ломающих изменений (MAJOR версия увеличивается, напр. v2.x -> v3.0.0):

1. Предыдущая мажорная версия переводится в статус Legacy.

2. Все новые и обновляемые реализации I обязаны удовлетворять контрактам двух версий одновременно: текущей (vM.x) и предыдущей (v(M-1).x).

3. Это требование действует на протяжении всего жизненного цикла vM.x до выхода v(M+1).0.

5.4. Политика устаревания (N-1 Rule)

• Обязательная поддержка: Только две последние мажорные версии (M и M-1).

• Опциональная поддержка: Версии M-2 и старше рекомендуются для работы с legacy-системами, но не требуются спецификацией.

• Пример: При наличии в экосистеме SI v1.x, v2.x и v3.x, реализация для v3.x обязана поддерживать v2.x, но не обязана поддерживать v1.x.

5.5. Техническая реализация двойной поддержки

Двойная поддержка реализуется внутри одной I и не является выделенным слоем:

• В статических средах: параллельная реализация двух контрактов с общим приватным ядром логики.

• В IPC/сетевых средах: проверка маркера версии в заголовке сообщения и ветвление парсера/маршрутизатора внутри процесса.

• В динамических средах: условная регистрация методов/обработчиков в зависимости от запрошенной версии контракта.

6. Контекстная адаптация интерфейсов

SI определяет что требуется, но не как это будет передано. Механизм привязки определяется контекстом развёртывания:

Правило: Выбор механизма привязки не вводит новых сущностей в граф зависимостей. Он конфигурируется на этапе сборки, развёртывания или инициализации окружения времени исполнения.

7. Идентификация соответствия спецификации

7.1. Формат маркера соответствия

Для явного указания уровня соответствия системы правилам FASA используется строковый идентификатор следующего формата:

FASA.<spec-version>-<punct1>.<punct2>...<punctN>

7.2. Реестр кодов соответствия (puncts)

7.3. Примеры маркеров

• FASA.1.0-na.vc.ac — система соответствует спецификации 1.0, соблюдает правила: отсутствие адаптеров, версионирование с поддержкой двух мажорных версий, ацикличность графа.

• FASA.0.9.3-na — частичное соответствие черновой версии 0.9.3, подтверждено только правило na.

• FASA.1.0-na.vc.ac.ui.cb.dt — полное соответствие всем базовым правилам спецификации 1.0.

7.4. Правила использования маркеров

1. Маркер размещается в метаданных проекта: README, package.json, Cargo.toml, заголовке репозитория или документации.

2. Указание маркера подразумевает наличие автоматизированных проверок (тестов, линтеров, CI-шагов), подтверждающих заявленные правила.

3. При обновлении спецификации проект должен явно обновить маркер (например, с FASA.0.9.3 на FASA.1.0), если подтверждает новые требования.

4. Частичное соответствие допустимо: можно указать только те punct, которые реализованы. Отсутствие кода означает, что правило не проверяется или не соблюдается.

8. Валидация и контроль соответствия

8.1. Чек-лист соответствия FASA

• Все SI не содержат ссылок на I

• Граф зависимостей является DAG (нет циклов)

• Каждая I зависит минимум от одного SI

• Отсутствуют выделенные адаптеры/транспортеры между I и SI

• UI не импортируется и не вызывается другими компонентами

• При MAJOR-обновлении SI все новые I удовлетворяют vM и v(M-1)

• Поддержка версий старше v(M-1) не требуется по умолчанию

• Инфраструктурные компоненты не вносят изменений в семантику SI/I

8.2. Инструментальная поддержка

• Статический анализ: Графовые анализаторы зависимостей, линтеры импортов, кастомные AST-проверки.

• Контрактные тесты: Автоматическая проверка, что I проходит наборы тестов для SI vM и SI v(M-1).

• CI-валидация: Автоматическая проверка ацикличности, направлений импортов и покрытия версионными тестами при каждом merge/push.

• Маркировка: Автоматическая генерация маркера соответствия на основе результатов проверок.

9. Иллюстративные примеры

Примеры носят демонстрационный характер и не привязаны к конкретному языку.

9.1. Управление памятью (in-process)

[SI: PageFrameManager v2] <- требует <- [SI: SyncPrimitive v1]         ^                              ^   [I: HeapAllocator v2.1] <- использует <- [I: MutexSpin v1.4]         ^      [UI: MemCLI v1.0]

• HeapAllocator реализует PageFrameManager v2 и одновременно v1 (правило N-1).

• Внутренне использует MutexSpin через SyncPrimitive v1.

• Никаких «memory abstraction layers» или «allocator adapters» не вводится.

• Маркер соответствия: FASA.1.0-na.vc.ac

9.2. Распределённый анализатор кода (IPC/Pipe)

[SI: LanguageProtocol v3] (JSON-RPC over stdio)         ^   [I: RustAnalyzer v3.2]         ^      [UI: EditorPlugin v2.5]

• SI определяет набор команд textDocument/didOpen, completion, и так далее.

• I читает stdin, разбирает JSON, проверяет поле jsonrpc или method-префикс версии, маршрутизирует к соответствующим обработчикам внутри одного процесса.

• При выходе v4 анализатор обязан продолжать корректно обрабатывать v3-запросы.

• Инфраструктура: балансировщик может распределять запросы между несколькими экземплярами I, но это не влияет на контракт.

• Маркер соответствия: FASA.1.0-na.vc.cb

9.3. Нарушение принципов FASA (анти-паттерн)

[SI: AuthService] -> [Adapter: AuthHttpBridge] -> [I: RealAuthService]

Запрещено: AuthHttpBridge является выделенным промежуточным слоем, который только транслирует вызовы. Его логика должна быть изолирована внутри RealAuthService или SI должен быть определён сразу как сетевой контракт.

10. Глоссарий