《后端架构设计·架构基础与边界》附录 A 术语表

怎么用这份术语表

这份表不追求词典式的完整定义，只回答三个问题：

1. 这个词在本书里指什么；
2. 它最容易和哪个词混；
3. 第一次系统展开在哪一章。

同一个词在不同团队可能有不同含义。本书的选择是：第一次出现时给英文和用法，之后保持一致；如果某个团队的习惯与本表不同，以团队内部约定为准，但要在 ADR 或接口文档里写清楚。

术语按主题分组，不按拼音排序。想查某个词，用页面搜索比从头翻更快。

一、领域建模

二、架构风格与边界

三、数据与一致性

四、接口与通信

五、运行与可用性

六、组织与治理

十组最容易混用的概念

子域与限界上下文

子域是问题空间的划分，回答“业务上有哪几块”；限界上下文是解决方案空间的边界，回答“哪一块模型必须保持一致”。一个子域可以对应多个上下文，一个上下文也可能横跨多个子域。第 3 章会用 arch-lab 的订单、库存、支付说明两者的对应关系。

聚合与模块

聚合是事务和并发的一致性边界，模块是代码和部署的组织单位。一个模块可以包含多个聚合；一个聚合也可能被多个模块读取。把聚合画成模块，通常会导致“一个大聚合管所有事”。

端口与接口

在本书里，端口特指领域需要的抽象，由外层实现；接口是 Go 语言层面的类型。端口一定是接口，但接口不一定是端口——内部的策略接口、测试替身接口都不承担隔离外层的职责。

事件与消息

事件表达“已经发生的事”，消息是传输载体。命令是“请求做一件事”，也常通过消息传输。三者可以共用一套基础设施，但语义和责任不同；第 7 章会给出对照表。

幂等与去重

幂等是效果承诺：执行多次与执行一次相同。去重是实现手段：识别并丢弃重复请求。去重窗口有限，窗口外的重复仍可能发生，所以关键操作还需要业务层的幂等设计。

最终一致与不一致

最终一致承诺“最终会收敛”，不承诺“永远不一致”。如果一个流程没有对账、没有补偿、没有收敛期限，它只是“不一致”，不是“最终一致”。

超时与重试

超时是放弃等待的边界，重试是再次发起的动作。没有超时的重试会把故障放大；没有预算的重试会让上游先崩。第 7 章和卷二会把两者放在同一条调用链上讨论。

熔断与限流

限流控制进入系统的流量，熔断控制对下游的调用。限流保护自己，熔断保护调用链。两者经常一起用，但解决的不是同一个问题。

部署单元与模块

模块是代码边界，部署单元是运行时和发布边界。模块化单体有很多模块，但只有一个部署单元；微服务通常一个模块一个部署单元，但不是必须。

架构决策与设计决策

架构决策影响多个团队、难以回退、需要跨模块协调；设计决策通常局限在一个模块内，可以由团队自行决定。不是所有决策都值得写 ADR，判断标准是“三个月后会不会有人追问为什么”。

五个容易过时的定义

有些词的定义会随行业宣传快速漂移。本书不追新口号，只保留可操作的判断。

微服务

过时定义：把应用拆成很多小服务。可操作定义：一组按业务能力组织、独立部署、独立拥有数据、通过明确契约通信的服务。判断一个系统是不是微服务，看数据所有权和发布独立性，不看容器数量。

中台

过时定义：把所有公共能力抽出来做成一个大平台。可操作定义：一组被多个业务线复用、有明确服务契约和 owner 的共享能力。没有复用方、没有契约、没有 owner 的“中台”，通常只是多了一层审批。

云原生

过时定义：上云、用 Kubernetes。可操作定义：以容器、声明式配置、可观测性和自动化发布为基础，让系统能按需伸缩和快速恢复的一组实践。用了 Kubernetes 但发布仍靠手工改配置，不算云原生。

领域驱动设计

过时定义：画很多 UML 图、写很多实体类。可操作定义：用限界上下文划分模型边界，用聚合保护业务不变式，用统一语言让业务和技术对齐。图是副产品，不是目的。

平台工程

过时定义：把运维团队改名为平台团队。可操作定义：把重复的交付、观测、安全能力做成自助产品，降低业务团队的认知负荷。判断标准是业务团队能否不排队地完成发布和排障，不是平台团队写了多少文档。

术语不是标准答案

这份表给的是本书的统一口径，不是行业标准。不同团队、不同框架、不同教材对同一个词可能有不同定义，这很正常。

重要的是三件事：

1. 在一个项目里保持前后一致；
2. 第一次出现时给出定义，而不是假设读者知道；
3. 发现定义冲突时，先对齐“要解决什么问题”，再争论词。

如果某个词在你的团队里含义不同，不必强行改口。把差异写进 ADR 或接口文档，比背一份“正确术语表”更有用。

术语与章节对照

常见缩写

使用建议

第一，遇到不确定的词，先看它在本书里的用法，不要直接套用其他团队的语境。同一个词在不同公司可能完全相反。

第二，写 ADR 或接口文档时，第一次出现的术语给英文和一句定义。读者不需要猜。

第三，团队内部如果有不同叫法，选一个作为正式名称，其他作为别名记录，不要在代码和文档里混用。

第四，不要把这份表当成考试范围。术语的价值在于让讨论更精确，不在于背定义。

第五，发现某个词在书里前后用法不一致，按“第一次出现时的定义”理解，并把位置记下来。那通常是需要修订的地方。

小结

这份术语表覆盖了卷一会用到的六组概念：领域建模、架构风格、数据一致性、接口通信、运行可用性和组织治理。每个词给出英文、本书用法和常见混淆，并在最后列出十组最容易混用的概念。

读正文时不必先背完；遇到拿不准的词，回来查一下，再继续。术语是讨论的工具，不是讨论的目的。

同一个词在招聘启事、论文、厂商文档里的含义也可能不同，看到时先判断语境，再决定是否套用本书定义。

这份表只覆盖卷一实际出现的词，不追求收录行业全部缩写。卷二、卷三遇到新词时，会在首次出现处单独说明，不要求读者来回翻附录。
如果某个词在书中出现却没有收录，说明它更接近通用编程概念，而不是本书定义的架构术语。
表格中标注“本书用法”的条目优先于通用定义；没有标注的条目按行业通用含义理解。