20 принципов, 7 характеристик, 1 метод: как не путать средства с целями в архитектуре
Принципы есть, а как проверить — непонятно
Я строю платформу для интеллектуальной работы. На этапе проектирования мы сформулировали 16 правил: модульный монолит, Git-first, роль ≠ исполнитель, и так далее. Назвали их «принципами».
И тут встал вопрос: как понять, что архитектура хорошая?
Первый порыв — пройтись по принципам как по чеклисту. «Модульность? Есть. Git-first? Да. Роль ≠ исполнитель? Конечно.» Всё зелёное?
Нет. Можно соблюдать все принципы и получить систему, которая масштабируется плохо, учиться ей долго, а скорость — ниже порога. Потому что принципы — средства, а не цели.
Четыре уровня принципов
Когда разобрали наши 16 правил, оказалось, что они перемешаны. Часть работает для любого проекта в домене, часть — только для конкретной системы, а одно — вообще универсально.
Разложили по четырём уровням:
Нулевые принципы — работают везде, в любой области. Транс-дисциплинарные аксиомы вроде закона сохранения энергии или принципа непротиворечивости. Мы на них не влияем, но они ограничивают всё остальное.
Первые принципы — фундамент для целых дисциплин. Из нашего фреймворка (FPF): «Роль ≠ Исполнитель» — это верно для любой организации, любой системы. Мы не дублируем их у себя, а ссылаемся на источник.
Вторые принципы — принципы конкретного домена. Вот это — наши. Они работают для любой платформы экосистемы развития интеллекта, не только для Aisystant. После разбора их стало 20. Примеры:
| # | Принцип | Что значит |
|---|---|---|
| 1 | Модульный монолит | Чёткие границы контекстов, но одна кодовая база |
| 2 | Git-first | Что не в Git — не существует |
| 7 | Context Engineering | Каждый вызов LLM начинается с Write/Select/Compress/Isolate |
| 14 | Continuous Knowledge Capture | Знание фиксируется в момент обнаружения, не «потом» |
| 16 | Test Through Bot | Каждая фича тестируется через реального пользователя |
Третьи принципы — решения конкретного проекта. Они привязаны к Aisystant и не переносятся на другую платформу:
- Neon PostgreSQL как единая база данных — конкретный выбор технологии
- Юрисдикции: RU-данные → RU-хостинг, EU-данные → EU-хостинг — регуляторное ограничение
Вторые принципы живут в базе знаний домена (Pack). Третьи — в проектных решениях (ADR). Первые — в фреймворке. Каждый на своём месте, каждый со своим жизненным циклом.
Ключевой поворот: принципы нельзя оценить
А теперь — главное.
Принцип бинарен. Ты его либо соблюдаешь, либо нарушаешь. «Платформа модульна на 85%» — бессмысленное высказывание. Модульность — ограничение проектирования, а не измеряемое качество.
Характеристика скалярна. «Платформа масштабируема на 85%» — имеет смысл. Масштабируемость — измеряемое качество конкретной системы.
Цепочка:
Принципы → ограничивают проектирование
Проектирование → порождает систему
Система → обладает характеристиками
Характеристики → можно измерить
Объект оценки — всегда система, никогда принцип. Мы не оцениваем принципы — мы проверяем, соблюдаются ли они (да/нет), а потом измеряем, какую систему они породили (по шкале).
Это не просто терминологическая тонкость. Путаница между средством и целью приводит к реальным проблемам: «мы соблюдаем все правила, значит архитектура хорошая» — классическая ловушка.
7 характеристик: ЭМОГССБ
Мы измеряем систему по семи характеристикам:
| Характеристика | Вопрос |
|---|---|
| Эволюционируемость | Что сломается при изменении? |
| Масштабируемость | Что будет при 10x нагрузке? |
| Обучаемость | Сколько нужно читать, чтобы начать? |
| Генеративность | Создаёт ли это платформу для нового? |
| Скорость | Какая задержка для пользователя? |
| Современность | Как эту задачу решают лучшие? Что пропустил? |
| Безопасность | Какие угрозы создаёт? Что экспонирует? |
Каждая — шкала от 1 до 10. Средний порог — 8. Если две или больше характеристики слабые — решение блокируется.
Метод: АрхГейт
Мы назвали этот процесс АрхГейт — блокирующая оценка архитектурного решения. Три шага:
Шаг 1. Принципы (до оценки). Сверяем решение с 20 принципами 2-го уровня. Нарушает принцип → исправляем до оценки. Бинарная проверка: соблюдает / нарушает.
Шаг 2. Оценка (характеристики). Оцениваем систему по ЭМОГССБ. Скалярная оценка: число по шкале 1-10.
Шаг 3. Обратная связь (после оценки). Если характеристика слабая — проверяем, какие принципы её защищают. Принципа нет → предлагаем новый. Принцип есть, но слаб → усиливаем.
Это цикл: характеристики подсказывают, каких принципов не хватает. В терминах FPF — ADI-цикл: принципы = абдукция (выдвигаем гипотезу), проектирование = дедукция (применяем), оценка = индукция (проверяем по результату).
Как это выглядит в деле
Когда оценивали целевую архитектуру платформы, средний балл ЭМОГССБ вышел 8.3. Почти всё зелёное. Но скорость = 7.
Проверили покрытие: скорость защищена всего двумя принципами из двадцати. Покрытие слабое. Рекомендация — добавить принцип «Latency budget per layer» (бюджет задержки на каждый слой архитектуры).
Без Шага 3 мы бы приняли решение со слабой скоростью и не заметили, что проблема — не в решении, а в недостающем принципе.
Кто всё это делает
Процесс формализован. Claude работает в роли Архитектор (R5 в каталоге ролей платформы). Метод — АрхГейт (DP.M.005). При оценке coupling задействуется сервис Consistency Check (S20, роль Синхронизатор).
Каждое архитектурное решение — до первого коммита — проходит через АрхГейт. ИИ работает по формализованному методу с тремя шагами, семью характеристиками и обратной связью. Принципы записаны в базе знаний. Характеристики определены. Метод описан. Роли назначены.
Если строите систему — попробуйте разложить свои правила проектирования по четырём уровням. Вероятно, обнаружите, что часть — не принципы, а характеристики, и наоборот. Это различение меняет логику принятия архитектурных решений.