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

复核基线：95b8611bd9bbc282193591e472e2e19c617e5035
状态：实现已验证，用户于 2026-08-17 确认当前架构

实际落地结构

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、契约、边界和部署验证

为什么当前拆分合适

前后端工程分开，但仓库不割裂。 Web 和 Server 有各自 package、构建与类型检查，责任清楚；根 workspace 只做质量编排。个人开发阶段仍能一次安装和验证，避免维护多个仓库与跨仓库版本同步。
不建立根共享 contracts 包。 HTTP 只有一个事实源：Server DTO 生成 OpenAPI，Web 再生成自己的类型。Web 无法直接引用 Server 源码，.vue 和 TypeScript 都有自动边界检查。这样比手工同步两份类型或共享内部类更明确。
一个 Server 工程、三个进程入口。 API、Scheduler、Worker 使用相同基础设施与消息契约，但启动、配置和部署彼此独立。当前规模下没有必要拆成三个仓库或三个重复 Nest 工程；未来可独立扩容进程而不复制公共代码。
配置是进程级最小权限。 API 不读取任务消费配置，Scheduler 不读取 MySQL/AI 密钥，Worker 不读取 API 端口。配置先校验和冻结，再通过动态模块注入，测试与生产使用同一装配路径。
基础设施通过 Adapter 隔离。 业务代码将依赖 MessageBus、Repository 和数据源端口；RocketMQ 客户端尚未验证时明确禁用，避免以临时内存队列形成错误语义。
生产只有一条源码路径。 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。

确认不代表架构永久冻结。市场概览全部业务完成后，仍需依据实际模块依赖、运行负载和维护成本再次论证；在此之前不得仅凭预期拆分微服务或共享契约包。

5.1 KiB Raw Permalink Blame History Unescape Escape