docs(acm2-75): 精简规范引言并重写术语表
- 删除引言段:唯一出处清单、编号规则与空缺说明按评审结论去除 - 术语表逐行改写为平话:库方收敛为 CIIMS adapter 方(信箱表在其 MySQL,表结构变更与清除归它,机制未定);上游收敛为 CIIMS adapter 写入,AODB 经它落信 - 落信涵盖兼容 HTTP 入口;处理标记标注与需求文档「处理时间」的对应 - 术语行去掉内部表名、编号括注与管道术语指针;处理完成、Redis 投影按 US-05/US-07 口径收窄 Redis 条件
This commit is contained in:
+12
-29
@@ -1,40 +1,23 @@
|
||||
# 规范:术语、契约、前提、不变量与声明边界
|
||||
|
||||
本文件是以下事实的唯一出处:
|
||||
|
||||
- 对外**术语**(本文件「术语」节);
|
||||
- 本系统与外部对手方的**承诺与要求** `C-x`,以及我们向库方/上游的单方承诺;
|
||||
- **待确认事项** `Qn` 注册表;
|
||||
- 外部提供的**前提** `PRE-x`;
|
||||
- 本系统保证的**不变量** `INV-x`;
|
||||
- **声明边界** `CLM-x`:每条对外主张依赖哪些 `PRE`/`INV`、可否声明、挂起原因;
|
||||
- **当前已知偏差** `G` 注册表;
|
||||
- **验证映射**:验收口径的唯一清单。
|
||||
|
||||
编号稳定不变;条款被取代时标 `[作废 by C-y]` 并保留原文,不静默改写。不变量变更用「追加 + 作废」(`INV-7 → [作废 by INV-7b]`)。机制与领域规则见 [implementation.md](implementation.md),参数取值见 [reference.md](reference.md)。
|
||||
|
||||
**编号空缺**:本文件成形前已作废的旧条款未随迁移保留原文,其号码空缺且不再复用(契约段缺第 17~19 号,声明边界段缺第 1、2 号)。
|
||||
|
||||
## 1. 术语
|
||||
|
||||
| 术语 | 含义 |
|
||||
|---|---|
|
||||
| 上游 | 向信箱写入报文的源头系统(CIIMS、AODB 等)。 |
|
||||
| 信箱 | 共享 MySQL 的入站表 `CMINMSGS`;出站方向为 `COUTMSGS`。 |
|
||||
| 库方 | 共享 MySQL 的管理方;表结构变更与数据清除只能由库方执行或书面授权。 |
|
||||
| 处理标记 | 信箱行上表示「本系统已处理」的约定字段;逻辑名 `DATE_PROCESSED` / `STATUS`,实际列名以库方契约为准。本系统只把空标记写成已处理值,不回撤、不覆盖。 |
|
||||
| 落信 | 报文进入信箱(`CMINMSGS` 存在该行),执行方是上游。 |
|
||||
| 入队 | 本系统在自有 PG 建立 `PROC_STATE` 记录,开始处理。 |
|
||||
| 上游 | 报文的写入方。现在是 CIIMS adapter,它把 AODB 下发的报文写进信箱。 |
|
||||
| 信箱 | CIIMS adapter 的 MySQL 里用于消息交换的表——入站 `CMINMSGS`、出站 `COUTMSGS`;报文由 adapter 写入,网关读取。 |
|
||||
| 库方 | CIIMS adapter 方。信箱表在它的 MySQL 里,表结构变更与数据清除由它执行,机制未定;本系统只读消息、写回处理标记,不改表结构、不清数据。 |
|
||||
| 处理标记 | 信箱行上表示「已处理」的字段,需求文档说的「处理时间」就是它。本系统只把空标记写成已处理值,不回撤、不覆盖。 |
|
||||
| 落信 | 报文进入信箱,成为其中一行。写入的是 adapter 或兼容 HTTP 入口。 |
|
||||
| 入队 | 本系统在自有 PG 给这条报文建立一条处理记录,开始处理。 |
|
||||
| 已回填 | 本系统已把处理标记写回该信箱行。 |
|
||||
| 处理完成 | 消息的业务数据已在自有 PG 落库、Redis 投影也写成功后的终态;Redis 写失败不算完成(`INV-23`)。 |
|
||||
| 投递确认 | 投递目标已接受且本地 `MSG_EVENT` 已置 `SENT`;不表示业务消费者已消费。 |
|
||||
| Redis 投影 | 本系统写入的航班查询投影;不是权威,也不是处理状态(`INV-11b`、`INV-24`)。 |
|
||||
| 自有 PG | 本系统唯一的业务数据库 PostgreSQL;与信箱之间不存在跨库事务。生产环境用 PostgreSQL 还是 Oracle 11g 未定,Oracle 适配验证通过前不构成支持承诺。 |
|
||||
| admin-api | 本网关处理结果的下游只读消费者;直接读取本系统写入的静态参考数据表(`C-31`),不向本系统提供数据。 |
|
||||
| 处理完成 | 消息处理完了:业务数据已写入自有 PG,该写的 Redis 投影也已写成功。 |
|
||||
| 投递确认 | 发出去的消息对方已接收,本系统的投递记录也记成已发送;这不代表对方的业务已经消费。 |
|
||||
| Redis 投影 | 本系统写进 Redis、供查询用的航班数据;完整数据在本系统的 PostgreSQL 数据库里。 |
|
||||
| 自有 PG | 本系统自己的业务数据库 PostgreSQL,处理结果都存在这里;与信箱之间没有跨库事务。生产环境用 PostgreSQL 还是 Oracle 11g,还没定。 |
|
||||
| admin-api | 下游查询系统;直接读本系统写入的静态参考数据表,不向本系统提供数据。 |
|
||||
|
||||
管道内部术语(队头、终态、待标记、回填意图)定义在 [implementation.md](implementation.md)「术语与持久化记录」。
|
||||
|
||||
条款状态词只有四种:`[待确认 Qn]`(未取得对方书面确认)、`[已确认 YYYY-MM-DD]`(对方书面确认且已回写)、`[我们单方承诺]`(对外承诺,不依赖对方,已生效)、`[我们自证]`(本系统自身的架构或部署事实,无需对方确认)。
|
||||
条款后面的状态标记有四种:`[待确认 Qn]`=还没拿到对方确认;`[已确认 YYYY-MM-DD]`=对方已确认并记录在此;`[我们单方承诺]`=不等对方、自己已生效的对外承诺;`[我们自证]`=本系统自身的部署事实,无需确认。
|
||||
|
||||
## 2. 契约
|
||||
|
||||
|
||||
Reference in New Issue
Block a user