Технологический стек
- Статус: draft
- Ответственный за заполнение и согласование: architecture-owner
- Версия базиса: заполнить
- Источник: указать входящий документ, его владельца, версию и применимые разделы либо принятое решение из реестра решений.
- Область действия: указать продукты, части системы и среды; инструменты разработки и проверки перечислять отдельно, если они тоже ограничены.
Назначение
Архитектор заполняет этот документ до выбора зависимых проектных решений. Стек может быть задан на входе или выбран при проектировании; происхождение каждого условия и его обязательность указываются явно.
Этот файл — единственный источник перечня технологий и правил версий. Каталог определяет части системы, состав связывает их с TECH-ID, развёртывание описывает размещение, а архитектурный REQ второго уровня закрепляет обязательность применения согласованного базиса.
Базис технологий
| ID | Назначение | Продукт / технология | Редакция и допустимая версия | Обязательность | Части и среды | Источник условия |
|---|---|---|---|---|---|---|
| TECH-OS | Операционная система | Заполнить | Заполнить | Входящее ограничение / проектный выбор / рекомендация | Заполнить | Документ и раздел либо DEC-ID |
| TECH-RUNTIME | Язык и среда исполнения | Заполнить раздельно язык и реализацию runtime | Заполнить | Заполнить | Заполнить | Заполнить |
| TECH-DATABASE | Транзакционная СУБД | Заполнить | Заполнить | Заполнить | Заполнить | Заполнить |
| TECH-OBJECT-STORAGE | Объектное хранилище | Заполнить либо обосновать неприменимость | Версия продукта либо условия управляемого сервиса | Заполнить | Заполнить | Заполнить |
Добавьте строки для значимых платформ, фреймворков, брокеров, поиска, наблюдаемости, сборки и поставки, если они требуются системе. Неприменимость объясните; незаполненная строка не означает свободу выбора. Секреты и реальные ключи доступа в документ не входят.
Совместимость и границы
Опишите требуемые сочетания ОС/runtime/СУБД, архитектуру процессора, протоколы, расширения и ограничения лицензий/поддержки. Ссылки на документацию производителя подтверждают опубликованные свойства; совместимость приложения подтверждается проверками конкретной сборки.
Укажите, какие зависимости команда может выбирать самостоятельно и какие должен согласовывать архитектор. Потребительский протокол и продукт различаются: совместимость с SQL, Java SE или S3 сама по себе не разрешает замену выбранного продукта.
Версии и замены
Задайте допустимые ветки и правило фиксации точных сборок/хешей в репозитории реализации и доказательствах приёмки. Для сервиса без открытой версии фиксируйте идентичность сервиса, конфигурацию и проверяемые возможности API.
Изменение обязательного продукта, ветки или области применения проходит через изменение этого базиса, разбор влияния и согласование архитектором. Исключение должно иметь область действия, причину, владельца, срок/условие окончания и связанные REQ; если исключений нет, так и напишите.
Приёмка и открытые вопросы
Свяжите обязательный стек с архитектурным REQ и сценарием инспекции состава сборки и среды. Запланируйте положительный случай, неподтверждённую замену и отсутствие точной версии; отдельно предусмотрите запуск, миграции, восстановление и необходимые протокольные проверки.
Нерешённые вопросы внесите в docs/questions.md, изменения — в impact/stretch-matrix.md. Линтер требований проверяет выбранные связи REQ/CHECK; содержимое этого документа оценивает агент и архитектор. Автоматическое сравнение инвентаризации со стеком добавляется при наличии регулярного потребителя, а не ради нового формата.