47 lines
2.8 KiB
Markdown
47 lines
2.8 KiB
Markdown
# ADR-0010：APS 开发期与本仓库同仓不同目录
|
||
|
||
- **状态**：已接受
|
||
- **日期**：2026-09-24
|
||
- **决策人**：技术负责人
|
||
- **相关**：任务表 B0；ADR-0008、ADR-0009；《架构设计》第 2 节
|
||
|
||
## 背景
|
||
|
||
《架构设计》第 2 节写的是「业务系统的代码不在这个仓库里」，ADR-0008/0009 也把 APS 当独立系统。但 APS 目前还在 `main` 分支里与平台混装，B0–B7 是把它拆出来的全过程。拆的过程中需要两个问题先有答案：
|
||
|
||
1. 开发期 APS 放哪？立刻新建独立仓库，还是先在本仓库里隔离出一个目录？
|
||
2. 这段过渡形态要不要写进 ADR，免得以后有人拿《架构设计》第 2 节说事？
|
||
|
||
## 选项
|
||
|
||
| 选项 | 做法 | 代价 | 不选的理由 |
|
||
| --- | --- | --- | --- |
|
||
| A 开发期同仓库 `aps/` 目录 | APS 代码放本仓库 `aps/`，独立工具链、独立 CI、独立库；迁出条件写进 ADR | 仓库体积与 clone 成本上升；边界靠规则而非物理隔离 | 选定 |
|
||
| B 立刻新建独立仓库 | B0 之前先建仓库、配权限、配 CI | 边界最干净 | APS 还有 39k 行在 `main` 里，没拆完就分仓会让搬迁与查证两头跑 |
|
||
| C 继续混装 | 不动结构 | 零成本 | 与 D8、ADR-0008/0009 全部冲突 |
|
||
|
||
## 结论
|
||
|
||
选 A：**开发期 APS 放本仓库 `aps/` 目录**，按独立系统对待。
|
||
|
||
| 项 | 结论 |
|
||
| --- | --- |
|
||
| 目录 | `aps/`；工具链 Python，与平台（TS）不共享依赖 |
|
||
| 依赖规则 | 平台代码不得引用 `aps/`；APS 不得引用平台的 TS 代码。两侧唯一的界面是 Provider 契约（HTTP） |
|
||
| CI | 独立 job；平台的 lint / typecheck / test 不因 APS 失败而阻塞，反之亦然 |
|
||
| 数据库 | APS 库归 APS（ADR-0008），仍要求独立账号、独立 database |
|
||
| 交付 | 仍按 ADR-0009：首版只交付纯平台包，APS 单独部署 |
|
||
| 与架构设计的关系 | 《架构设计》第 2 节描述的是最终形态；本文定的是**开发期过渡形态** |
|
||
| 迁出条件 | 满足任一条即迁出独立仓库：① APS 需要独立发版节奏；② APS 由独立团队维护；③ 平台包发布流程需要隔离权限 |
|
||
|
||
## 影响
|
||
|
||
- **对代码**：新增 `aps/` 目录；平台侧只在 `providers/aps` 里写适配器，不直接引用 `aps/`
|
||
- **对任务**：B0 的第一个产出物从「定仓库位置」改为「定 `aps/` 目录结构与迁出条件」；B1–B7 在 `aps/` 里做
|
||
- **对文档**：《架构设计》第 2 节补一句开发期说明；术语表「业务系统」条目无需改
|
||
- **不这么做的后果**：B0 卡在仓库创建上无法启动；或者继续混装，拆到一半两套工具链互相牵制
|
||
|
||
## 遗留
|
||
|
||
- 迁出时机的判断人：技术负责人；触发时按本 ADR 的迁出条件走
|
||
- `aps/` 与 `platform` 的 CI 分流细节：A1.6 落地时一并写进工作流 |