От Architecture Baseline к рабочему Full Stack MVP: как не усложнить архитектуру раньше времени

Вот важная новость с фронта ИИ: AndrejGV 12 минут назад Объяснить с От Architecture Baseline к рабочему Full Stack MVP: как не усложнить архитектуру раньше времени Средний 12 мин 365 Анализ и проектирование систем * . NET * ReactJS * PostgreSQL * Проектирование API * Аналитика В предыдущей статье разбирал как спроектировать корпоративную GenAI платформу до начала реализации: определить границы системы, разделить Core API и AI workloads, зафиксировать NFR, выбрать PostgreSQL + pgvector, определить security boundaries и сохранить ключевые решения в ADR. Но Architecture Baseline сам по себе ничего не доказывает.

Следующий шаг не RAG и не подключение LLM а проверка архитектуры одной рабочей вертикалью. Для этого используется Chats: намеренно простой сценарий, который должен пройти весь путь React > Core API > PostgreSQL и при этом не потребовать пересмотра принятых архитектурных решений. Проверка Architecture BaselineПосле архитектурного этапа легко уйти либо в бесконечное проектирование, либо слишком рано объявить архитектуру законченной.

Технические детали

Architecture Baseline должен задавать направление реализации, но его состоятельность всё равно нужно проверить реальным вертикальным срезом. Ранее было принято несколько принципиальных решений:Core API -> Modular Monolith Web -> React + TypeScript persistent state -> PostgreSQL data access -> EF Core AI workloads -> отдельные компоненты deployment MVP -> без KubernetesПереход к реализации не требует пересмотра этих архитектурных решений. Он проверяет, можно ли провести пользовательскую операцию через всю систему и при этом сохранить заявленные границы.

Поэтому критерий успеха здесь не:приложение запускается. А:frontend обращается к стабильному HTTP контракту, Core API выполняет прикладную операцию, состояние сохраняется в PostgreSQL, инфраструктурные ошибки наблюдаемы, а основное поведение воспроизводимо автоматическими проверками. Это уже значительно ближе к архитектурной готовности.

Физическая структура должна следовать архитектуреПосле C4 и ADR архитектурные блоки впервые начинают превращаться в реальные директории и проекты. Текущая структура репозитория выглядит примерно так:enterprise-genai-platform/ ├── docs/ ├── scripts/ ├── src/ │ ├── core-api/ │ └── web/ ├── tests/ │ └── core-api-tests/ ├── compose. yaml ├── EnterpriseGenAIPlatform.

Отраслевые последствия

jsonЗдесь важно не количество проектов, а соответствие границ ответственности: core-api это основной backend, web это его клиент, tests это автоматическая проверка поведения, docs это архитектурные решения, scripts это воспроизводимая проверка репозитория. При этом логическая граница ещё не означает необходимость отдельного процесса. Модуль это ещё не сервис.

Почему Core API всё ещё Modular MonolithВ Architecture Baseline Core API был зафиксирован как Modular Monolith. Первая реализация не дала причины это решение менять. Сейчас фактически реализован один функциональный модуль Chats.

Остальные области являются следующим развитием платформы.

Событие, по словам экспертов, усилит конкуренцию в сфере ИИ.