# 前后端项目架构复核与论证

- 复核基线：`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/                      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 入口，由 systemd 和 Nginx 管理；源码发布门禁验证这些路径一致，避免维护第二套构建和运行语义。

## 适合下一阶段的扩展方式

- 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` 标签。