Архитектура HAN Chat
Канонический набор архитектурных документов проекта. Описывает границы системы, интеграции, контракты API, инфраструктуру, настройки и процесс разработки.
Детальная схема таблиц App DB, правила проверки файлов (file_rules и др.) и OpenAPI-файлы — зона ответственности соответствующих модулей; архитектура задаёт только границы, контракты и общие правила.
Состав документов
| Документ | Содержание |
|---|---|
arch-00-glossary.md |
Канонические имена и семантика enum/lifecycle: сущности, поля, id, enum, бакеты S3, env |
arch-01-system-architecture.md |
Общая архитектура: компоненты, сценарии, потоки данных, безопасность |
arch-02-api-contracts.md |
Реестр API-контрактов, realtime, гостевая сессия, OpenAPI, аудит |
arch-03-docker-compose-blueprint.md |
Требования к Docker Compose, nginx, сетям, TLS и rate limits |
arch-04-settings-and-content.md |
.env (infra), таблица app_settings, значения service-token переменных, типы файлов |
arch-05-agent-development-process.md |
Правила разработки модулей отдельными агентами |
arch-06-service-hosting-security.md |
Безопасность VM и деплоя: OS-роли, SSH, sudo/systemd, секреты, контейнеры, сеть и lockdown |
Как читать
- Начните с arch-01 — общая картина и зафиксированные решения MVP.
- При работе с API — arch-02; с Compose/nginx — arch-03; с настройками — arch-04; с VM, SSH, правами деплоя, секретами и host/container hardening — arch-06.
- Спорные имена полей, id, enum, бакетов и базовая семантика enum/lifecycle — arch-00. Лимиты и правила реализации остаются в профильных arch-*.
- Перед разработкой модуля — arch-05, релевантные разделы arch-01/arch-02 и arch-06, если меняются deployment, сети, volumes, capabilities или секреты.
Приоритет документов
При конфликте требований:
- arch-00 — имена и базовая семантика (поля, id, enum, бакеты, env, смысл статусов); не бизнес-лимиты и не детальная реализация.
- arch-01 — границы сервисов, сценарии, sync, безопасность.
- arch-02 — HTTP-контракты и направление вызовов.
- arch-06 — безопасность размещения на VM, OS-роли, SSH, secrets delivery, host/container hardening и production-деплой.
- arch-03 — Compose, сети контейнеров, nginx и TLS.
- arch-04 — non-secret env, secret references,
app_settings, публичные DTO. - arch-05 — процесс разработки.
Профильные спецификации модулей уточняют реализацию внутри этих границ. Если границы не позволяют эффективно реализовать модуль, то агент, разрабатывающий модуль, может предложить внести изменения в архитектуру.
Разрешение конфликтов
- Имена полей, бакетов, статусов → arch-00, затем синхронизация arch-*.
- Endpoint или auth → arch-02, при необходимости arch-01/arch-03.
- Новая интеграция → сначала arch-02.
- Compose, nginx, TLS → arch-03.
- VM, SSH, sudo, systemd-деплой, secret delivery, container/host hardening → arch-06, затем синхронизация arch-03/arch-04 и runbook.
В бэклоге (не MVP)
| Тема | Где зафиксировано |
|---|---|
Доставка документов компании из Bitrix24 в приложение (bitrix-sync → api-backend, уведомление клиента) |
!Backlog.md, п. 9; arch-01 — заглушка UI «Документы» |
Интеграция с SMS-провайдерами (отправка OTP, отключение KEYCLOAK_OTP_MOCK_*) |
Спецификация: module-11-idgtl-sms.md (доставка через Direct SMS API; проверка OTP — локально в Keycloak) |
Каноническое размещение production-контуров
- ВМ1 HAN Chat — самостоятельная публичная точка входа приложения: nginx,
api-backend, Keycloak,bitrix-local-app, SMS-контур, Redis DB0/DB1 и локальный OTEL Collector. - ВМ2 Processing — самостоятельная service VM с отдельным public webhook host, private Message Safety ingress и постоянным ограниченным egress:
message-safety,bitrix-sync,clamd/freshclam, отдельный Redis Safety, nginx и локальный OTEL Collector. - На каждой VM действует один root Compose project и отдельный root-owned systemd deployment unit. «Единый Compose» означает один проект на VM, а не один общий project через несколько хостов.
- Bitrix24 вызывает CRM webhook напрямую на nginx ВМ2; ВМ1 в route не участвует. ВМ1 вызывает только Message Safety по private HTTPS.
- При росте нагрузки
bitrix-syncможет быть перенесён на ВМ3 без изменения API и границ схем PostgreSQL.
Открытые пробелы
| # | Пробел | Статус |
|---|---|---|
| G8 | Явный список is_public=true для ключей app_settings |
Отложить до оформления сервисов; seed в модуле database |
| G9 | GRANT-модель bitrix_sync_user на han_app: таблицы, колонки, read/write границы |
Закрыто в module-07-bitrix-sync.md §13; точный SQL реализуется migrations и проходит negative permission tests |
| G10 | Полный DTO GET /api/v1/public/app-config и мэппинг setting_key → response field |
Уточнить при оформлении OpenAPI api-backend |
| G11 | Версионирование API/WS: deprecation policy, срок поддержки v1, ws_protocol_version |
Уточнить перед публичным релизом API |
| G12 | Масштабирование realtime: Redis Pub/Sub, sticky sessions, backpressure при нескольких репликах api-backend |
Post-MVP / перед горизонтальным масштабированием |
| G13 | Contract tests между api-backend, message-safety, bitrix-local-app, bitrix-sync |
Контракт sync зафиксирован в module-07 §18; общий межсервисный gate остаётся до появления всех OpenAPI |
Обновление документации
- Изменение MVP → arch-01 + arch-02 (+ arch-03/arch-04 при необходимости).
- Новый env или ключ
app_settings→ arch-04. - Новая VM, изменение сетевой доступности, прав
deploy, sudo/systemd, capabilities, volumes или способа доставки секретов → arch-06 (+ arch-03/arch-04 и deployment runbook). - Новый термин / enum → arch-00, затем поиск по arch-*.
- Закрытие пробела → убрать из «Открытые пробелы» и отразить решение в arch-*.