《后端架构设计·架构基础与边界》目录与学习路径

本卷要解决的问题

卷一不教 Go 语法，也不教 Kubernetes 命令。它只回答一个问题：当一个后端系统从“能跑”走向“多人改、长期跑、必须评审”时，哪些边界必须先画清楚，才能避免后面用加班和事故补课。

具体拆成四件事：

1. 把“架构”从架构图还原成可验证、可回退的决策；
2. 把业务边界、数据边界、模块边界写成代码和测试能检查的东西；
3. 把接口、异步、演进、组织、安全、部署这些横切问题放进同一套判断框架；
4. 用一个贯穿项目 arch-lab 走完从需求到评审的完整链路。

卷二处理性能与可用性，卷三处理分布式与一致性，卷四处理演进与治理。本卷遇到这些题目时只划边界，不展开实现。

全书结构：13 章分四段

13 章不是 13 个孤立专题。每一章都往 arch-lab 里加一层可运行或可检查的产物，最后一章把这些产物串成一次可复现的架构评审。

章节依赖图

第 1 章 问题与质量属性
   │
   ├──► 第 2 章 表达与决策（C4 / ADR / 评审）
   │        │
   │        └──► 第 12 章 收口（需求→模块→风险）
   │
   ├──► 第 3 章 业务边界（子域 / 事件风暴 / 聚合）
   │        │
   │        └──► 第 6 章 数据边界（所有权 / 事务 / CQRS）
   │
   ├──► 第 4 章 模块化（模块 / 端口 / 防腐层）
   │        │
   │        └──► 第 5 章 接口与契约（资源 / OpenAPI / 错误）
   │
   ├──► 第 7 章 同步与异步（耦合 / 事件语义 / 幂等）
   │
   ├──► 第 8 章 演进（绞杀者 / 双写 / 适应度函数）
   │
   ├──► 第 9 章 组织（康威 / 决策权 / 治理）
   │
   └──► 第 10–11 章 安全与部署（身份 / 分级 / 故障域 / 配置）
            │
            └──► 第 13 章 综合（需求→ADR / 评审 / 进入卷二）

这张图只表达“先读什么更顺”，不是硬依赖。第 5 章可以在第 3 章之前读；第 9 章可以独立读；第 12 章必须放在第 2、3、4、6 章之后，因为它要把这些产物装配起来。

十三章速览

第 1 章 架构问题与质量属性

用一个把所有逻辑塞进 handler 的朴素订单服务，暴露状态、并发、故障、变更、观测、安全六类代价，再把状态机、质量属性场景和风格选型落成 arch-lab 的第一组约束。

产出：显式状态机与穷举测试、六条可测场景、ADR-001/002。

第 2 章 架构表达与决策

把上一章的约束画成 C4 四级视图，写成五份带备选方案的 ADR，再用一次评审演练和风险台账检验这些决策是否经得起追问。

产出：四级视图、ADR-003 至 ADR-007、八条以上风险的台账。

第 3 章 业务边界与领域建模

从子域划分走到限界上下文，再用一次事件风暴工作坊产出订单域的命令、事件、聚合和策略，最后回答订单聚合该多大、哪些一致性必须放进同一个事务。

产出：上下文映射表、事件目录、聚合清单与不变式测试。

第 4 章 模块化与依赖治理

说明模块化单体如何组织成未来可拆分的模块，把端口与适配器落到 arch-lab 的订单、库存、支付三个端口上，再用防腐层隔离第三方支付渠道。

产出：模块描述符与校验器、端口契约测试、支付 ACL 与状态映射测试。

第 5 章 接口与契约

从订单 API 的资源边界与命令语义出发，讨论契约优先的 OpenAPI 工作流，最后处理错误模型、版本演进和兼容窗口。

产出：订单 API 契约、错误码表、兼容性检查脚本或测试。

第 6 章 数据边界与所有权

回答订单数据该归谁、放在什么存储里，如何用本地事务加出站表保证最终一致，以及 CQRS 在什么条件下才值得引入、什么条件下应该退出。

产出：存储选型 ADR、outbox 表与发布器、CQRS 引入判据。

第 7 章 同步与异步的边界

分析同步调用链的隐性耦合，区分事件、命令与消息的语义，最后把幂等责任分配到 API、领域和消息层，写清每一层到底负责什么。

产出：调用链超时预算、消息语义对照表、幂等责任矩阵。

第 8 章 演进策略

讲绞杀者模式与增量迁移、分支抽象与双写/双读，最后把架构规则写成适应度函数，让边界在 CI 里持续被检查。

产出：迁移步骤与回退条件、双写对账方案、依赖与契约测试。

第 9 章 组织与架构

把康威定律落到团队边界与系统边界的关系上，讨论架构决策权如何分配、团队契约如何写，最后给出一套最小治理流程。

产出：团队拓扑映射、决策权矩阵、评审与例外流程。

第 10 章 安全与信任边界

从用户身份、服务身份和授权模型讲起，处理输入边界与数据分级，最后聚焦第三方支付渠道的信任边界、回调验签与密钥管理。

产出：身份与授权边界表、数据分级规则、支付回调安全测试。

第 11 章 部署单元与运行时边界

回答订单系统该切成几个部署单元、故障域怎么划，配置与密钥如何隔离环境差异，以及有状态服务的边界在哪里。

产出：部署单元图、配置分层规则、有状态服务恢复方案。

第 12 章 卷一收口：arch-lab 模块化单体基线

把前十一章的产物装配成一个可运行的模块化单体基线：需求与约束、初始架构与模块划分、质量属性场景与风险清单，并给出第一次 L2 端到端验证。

产出：基线架构说明、模块图、L2 端到端脚本与风险清单。

第 13 章 卷一综合

从需求走到 ADR，完整评审一次架构方案，处理反对意见与遗留风险，最后把问题清单交接给卷二。

产出：需求到决策的追踪链、完整评审记录、卷二问题清单。

三条阅读路径

路径 A：顺序通读

适合第一次系统补架构知识、准备技术评审或面试的读者。

总计约 30–36 小时。代码量不大，但每章都要求动手跑一次测试或检查命令，跳读会丢掉最重要的部分。

路径 B：评审驱动

适合手上正有一份方案要评审、或正在被评审的读者。

按这个顺序读：

1. 2.3 一次真实评审记录与风险台账
2. 12.3 质量属性场景与架构风险清单
3. 13.2 评审一次真实架构方案
4. 回到 2.1 C4 四级视图 和 2.2 五个 ADR 补齐表达方式
5. 用附录 C 架构评审清单 做一次自查

这条路径不追求读完全书，追求在一次评审前把“问什么、看什么、怎么记录反对意见”准备好。

路径 C：问题驱动

适合线上或项目里已经有具体症状的读者。先查表，再跳章。

arch-lab：贯穿项目

全书用一个订单交易系统 arch-lab 串起来。它不是玩具 demo，也不是生产系统，而是一个足够小、可以完整讲清边界；又足够真、每个决策都有代价的样本。

领域与 API

• 聚合：Order、InventoryReservation、Payment。
• 状态：CREATED → INVENTORY_RESERVED → PAID → FULFILLED，以及 CANCELLED、REFUNDED 两条旁路。
• API：创建、查询、取消、支付回调、列表五个端点。
• 存储：卷一首选 PostgreSQL 单写库；L1 测试用内存适配器。

代码分级

每段代码都标了运行级别，读者可以按需选择验证深度：

卷一大部分章节是 L1；第 12 章至少一个 L2；至少一次 PostgreSQL L3 端到端。文中出现“实测”时，必须附命令、机器和原始输出；没有跑过的数字统一写成“目标值/示例参数”。

代码标记

书稿里的 Go 代码块用三行注释标记来源和验证方式：

// file: internal/order/order.go
// tier: L1
// verify: go test ./internal/order/
package order

file 是抽取后的相对路径，tier 是运行级别，verify 是应该执行的命令。这些标记让代码可以被脚本抽取到临时模块里编译，而不是只供阅读。

验证命令

读完一段代码，至少跑一次对应级别的命令。不要只看输出截图。

每篇的组织方式

为了让不同章节可以独立阅读，每篇基本遵循同一结构：

这个结构不是八股。它的目的是让读者在任何一篇都能找到“问题是什么、代码在哪、边界在哪”，而不是读完只记住几个名词。

Go 主线，Java 对照

本卷以 Go 1.26 为主线，因为它的标准库足以把边界问题讲清楚，不需要框架遮住结构。Java 21 只做对照，不做第二套完整实现。

对照的口径：

• 只对照结构与语义，不比较语法优劣，也不做 Spring 生态对照；
• Java 代码只用 JDK 自带 API，不引入 Maven/Gradle；
• 本机默认 Java 不是 21，任何 Java 21 结论必须用 eclipse-temurin:21-jdk 容器实际运行；
• 没有在容器里跑过的结论，写成“预期行为”，不写“实测”。

常见的对照点包括：Go 的接口与 Java 的 sealed interface/record、Go 的 goroutine 与 Java 21 虚拟线程、Go 的 error 值与 Java 的异常层次、显式状态机与 enum 状态机。具体速查放在附录 B 。

版本与工具口径

书中出现的版本号以实际验证过的环境为准，不用“最新版”含糊带过：

版本会变，判断方法不会。遇到 API 差异时，先查当前版本文档，再决定是改代码还是改结论。
书中所有“本机输出”都注明机器与命令；没有注明的数字，一律按目标值或示例参数理解。

六个常见误区

第一，把架构图当架构。图上箭头画得再漂亮，代码里没有依赖检查，半年后方向就会反过来。卷一的每一条边界都会配一个可执行检查。

第二，先拆微服务再找边界。拆分不是架构起点，是边界清楚之后的结果。第 4 章先讲模块化单体，第 8 章才讲怎么迁。

第三，用技术分层代替业务边界。controller/service/repository 是代码组织方式，不是限界上下文；真正的边界由业务变化频率、数据所有权和团队归属决定。

第四，ADR 写成会议纪要。ADR 的核心不是“我们开了会”，而是“备选方案是什么、为什么否决、什么条件下重新评估”。

第五，质量属性没有度量。“高可用”不是需求，“支付网关超时时，订单服务在 200ms 内失败并释放库存，超时请求可统计”才是。

第六，把卷二、卷三的问题提前到卷一解决。卷一不解决高并发和分布式共识，它只确保边界画对，让后面的性能和一致性优化有地方落。

读完本卷的标准

不是“看完 45 篇”，而是能独立产出下面五样东西：

1. 一份 arch-lab 的 C4 四级视图，能说清每级给谁看；
2. 五份带备选方案与否决理由的 ADR；
3. 一张风险台账，每条风险有触发条件、负责人和关闭条件；
4. 一组模块依赖与端口契约测试，能在 CI 里跑；
5. 一次完整的架构评审记录，包括反对意见和结论。

如果这五样能写出来，卷二到卷四的性能、一致性和治理才有可讨论的对象。否则读得再多，也只是换了一套名词。

从哪开始

第一次读，从1.1 后端架构到底在解决什么问题 开始。手上有具体问题，直接用上面的症状表跳转。要评审方案，先读2.3 评审记录 。

全书完整篇目见卷一目录索引 ，或按顺序从 1.1 走到 13.3。