a-share-analysis/docs/features/GOV-009-application-scaffold-baseline/architecture-review.md

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

• 复核基线：95b8611bd9bbc282193591e472e2e19c617e5035
• 状态：实现已验证，等待用户确认

实际落地结构

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