docs(GOV-009): 封存脚手架复核材料

2026-08-13 19:55:45 +08:00
parent 95b8611bd9
commit f50268b70f
15 changed files with 290 additions and 2 deletions
@@ -0,0 +1,57 @@
+# 前后端项目架构复核与论证
+
+- 复核基线：`95b8611bd9bbc282193591e472e2e19c617e5035`
+- 状态：实现已验证，等待用户确认
+
+## 实际落地结构
+
+```text
+repository
+├── web/                         Vue 3 独立工程
+│   └── src/
+│       ├── app/                 应用装配、路由和根视图
+│       ├── api/generated/       OpenAPI 自动生成类型
+│       ├── api/adapters/        面向页面的稳定数据适配
+│       └── styles/              Sass 全局样式与后续 token 入口
+├── server/                      NestJS 独立工程
+│   ├── apps/api/                HTTP 与 OpenAPI 入口
+│   ├── apps/scheduler/          只负责任务触发的无 HTTP 进程
+│   ├── apps/worker/             任务执行的无 HTTP 进程
+│   └── libs/
+│       ├── config/              三进程最小权限配置契约
+│       ├── http-contracts/      Server DTO
+│       ├── message-contracts/   Server 内部 RocketMQ 信封
+│       └── infrastructure/      Redis、MySQL、消息与生命周期适配
+├── deploy/                      Compose、systemd、Nginx、env 模板
+└── tools/                       治理、Schema、契约、边界和部署验证
+```
+
+## 为什么当前拆分合适
+
+1. **前后端工程分开，但仓库不割裂。** Web 和 Server 有各自 package、构建与类型检查，责任清楚；根 workspace 只做质量编排。个人开发阶段仍能一次安装和验证，避免维护多个仓库与跨仓库版本同步。
+2. **不建立根共享 contracts 包。** HTTP 只有一个事实源：Server DTO 生成 OpenAPI，Web 再生成自己的类型。Web 无法直接引用 Server 源码，`.vue` 和 TypeScript 都有自动边界检查。这样比手工同步两份类型或共享内部类更明确。
+3. **一个 Server 工程、三个进程入口。** API、Scheduler、Worker 使用相同基础设施与消息契约，但启动、配置和部署彼此独立。当前规模下没有必要拆成三个仓库或三个重复 Nest 工程；未来可独立扩容进程而不复制公共代码。
+4. **配置是进程级最小权限。** API 不读取任务消费配置，Scheduler 不读取 MySQL/AI 密钥，Worker 不读取 API 端口。配置先校验和冻结，再通过动态模块注入，测试与生产使用同一装配路径。
+5. **基础设施通过 Adapter 隔离。** 业务代码将依赖 MessageBus、Repository 和数据源端口；RocketMQ 客户端尚未验证时明确禁用，避免以临时内存队列形成错误语义。
+6. **部署方式共享同一产物。** Ubuntu 源码部署使用 Web dist 与三个 Server dist 入口；现有 Docker Compose 只作为可选交付适配层复用这些产物，不形成第二套应用逻辑。按用户 2026-08-13 的决定，日常开发不再构建 Docker，待核心功能完成后再决定保留或移除。
+
+## 适合下一阶段的扩展方式
+
+- Web 市场概览应建立一个可连续阅读的 `features/market-overview/` 业务目录，内部按页面、数据适配和状态拆分；短线与中长线作为市场概览下的模式，不拆成两个独立应用。
+- Server 在 API/Scheduler/Worker 各入口内注册同一市场概览业务能力的不同适配面；共享领域模型和规则计算放入稳定业务库，HTTP DTO、消息 DTO 与数据库实体继续分离。
+- 用户体系、订阅和权限暂不加入当前业务模型；未来通过独立功能档案增加，不让其反向污染市场概览核心。
+- 当某个业务域出现独立发布节奏、团队所有权或明显扩容边界时，再论证拆包或拆服务；当前提前微服务化只会增加契约、部署和运维成本。
+
+## 已知限制
+
+- 当前 Web 只是工程外壳，没有市场概览 UI、行情图表和分析工作台。
+- RocketMQ 只有契约和禁用 Adapter，尚未选择并验证 Node 客户端。
+- TypeORM 已固定安全选项，但尚无业务实体和迁移。
+- 用户体系和订阅能力按用户决定后置，不在 GOV-009 范围。
+- Docker 交付方式尚未最终确认；现有文件和历史验证保留，但不能据此推定最终生产一定采用容器部署。
+
+## 复核结论
+
+现有架构适合“先做市场概览、个人使用为主、未来可扩展订阅”的阶段：边界清晰、运行方式简单、契约可自动校验，也保留 API/Scheduler/Worker 独立扩容路径。它不是不可变终局；完成市场概览真实业务后，仍应根据模块依赖和运行数据再次复核，而不是凭脚手架预判过度拆分。
+
+用户确认本论证前，GOV-009 保持 `reviewing/unreleased`，不得创建 `v0.0.8` 标签。