62 lines
5.1 KiB
Markdown
62 lines
5.1 KiB
Markdown
# 前后端项目架构复核与论证
|
||
|
||
- 复核基线：`95b8611bd9bbc282193591e472e2e19c617e5035`
|
||
- 状态：实现已验证，用户于 2026-08-17 确认当前架构
|
||
|
||
## 实际落地结构
|
||
|
||
```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 独立扩容路径。它不是不可变终局；完成市场概览真实业务后，仍应根据模块依赖和运行数据再次复核，而不是凭脚手架预判过度拆分。
|
||
|
||
## 架构确认记录
|
||
|
||
用户已于 2026-08-17 完成最终确认，同意以本文描述的实际结构作为当前业务开发基线：Vue 3 与 NestJS 工程分离维护，Server 保持 API、Scheduler、Worker 三进程，HTTP 契约沿 Server DTO → OpenAPI → Web 类型单向发布，生产交付仅支持 Ubuntu 源码部署。该确认满足 GOV-009 的最终完成门禁，GOV-009 与 GOV-010 一并归入 `v0.0.8`。
|
||
|
||
确认不代表架构永久冻结。市场概览全部业务完成后，仍需依据实际模块依赖、运行负载和维护成本再次论证；在此之前不得仅凭预期拆分微服务或共享契约包。
|