1. 异常边界辨识策略
边界是系统故障传播的天然屏障，也是组件化测试的基准线。本章定义五类核心边界，并给出每一步的识别方法，为后续的异常隔离和组件化测试奠定基础。
1.1 边界定义矩阵
| 边界类型 | 定义 | 典型识别方法 | 示例 |
|---|---|---|---|
| 业务边界 | 由业务领域、功能模块、用户故事划分的逻辑边界 | DDD 限界上下文分析、用户旅程切分 | 订单服务 vs 支付服务 |
| 技术边界 | 由技术栈、框架、协议或中间件差异形成的边界 | 架构拓扑图、调用链工具、依赖分析 | HTTP ↔ gRPC 转换层 |
| 运行时边界 | 进程、线程、容器、VM 等执行环境之间的隔离边界 | 进程列表、容器编排清单、线程转储 | Pod A ↔ Pod B 的通信 |
| 数据边界 | 数据库、缓存、文件系统、消息队列之间的数据所有权与一致性边界 | 数据流图、ER 图、CDC 监控 | 写库 vs 读库 |
| 安全边界 | 身份认证、授权、网络隔离、加密传输的信任域边界 | 安全架构评审、渗透测试、IAM 策略审计 | 公网 ↔ VPC 边界 |
1.2 辨识策略三步法
- 从业务出发：将业务功能拆解为独立 bounded context，每个 context 内聚一个核心实体与行为。
- 映射到技术实现：为每个 bounded context 分配专属服务、数据库、通信协议，标记技术栈变化点。
- 评估运行时与安全约束：检查进程隔离需求、数据仲裁域、信任模型，补充运行时边界和安全边界。
常见误判：将“数据库分表”直接当作数据边界——数据边界必须对应逻辑所有权变更，而不只是物理存储拆分。
1.3 系统分层与边界映射
典型分层架构中，边界通常出现在以下层间接口：
- 表现层 ↔ 应用层：业务边界（用户用例 → 应用服务）
- 应用层 ↔ 领域层：领域逻辑边界
- 领域层 ↔ 基础设施层：技术边界（ORM、消息、外部 API）
- 服务 ↔ 服务：运行时边界（进程级隔离）
1.4 控制流与数据流跨越边界
每个边界都意味着控制权和数据所有权的转移。下图展示了五类边界在典型微服务系统中的位置与关系。
1.5 信任链路与边界守卫
每个边界都需明确信任模型：
- 零信任边界：跨安全/运行时边界时，必须验证身份、加密通道。
- 半信任边界：技术边界内部（如同进程内模块）可省略部分校验，但数据一致性仍需要契约验证。
- 全信任边界：业务边界内（如同一个 bounded context）可依赖强一致性。
1.6 方案权衡与落地决策
| 策略 | 优势 | 代价 | 适用场景 |
|---|---|---|---|
| 粗粒度边界 | 开发简单、调用链短 | 故障面大、测试不精准 | 早期原型、低频变更 |
| 细粒度边界 | 隔离性好、测试精确 | 部署复杂、延迟增加 | 高并发、高SLA、多团队协作 |
| 运行时独享资源 | 完全隔离 | 资源浪费 | 安全关键模块 |
| 共享资源+契约测试 | 资源利用率高 | 需要强契约保障 | 内部基础设施层 |
1.7 落地步骤
- 绘制业务全景图，标记 bounded context（业务边界）。
- 逐 context 识别技术栈差异（技术边界）与进程隔离需求（运行时边界）。
- 定义数据所有权归属与仲裁域（数据边界）。
- 梳理跨边界信任模型，配置加密与认证策略（安全边界）。
- 为每个边界编写接口契约文档，作为后续组件化测试的输入。
1.8 验收标准
- 每个 bounded context 有明确的业务边界定义文档。
- 跨边界调用必须经过至少一项技术边界检查（协议、版本、序列化）。
- 运行时边界对应独立部署单元（容器/进程）且可以单独启停。
- 数据边界两侧数据库无乱写乱读，仲裁域已定义。
- 安全边界上的认证、加密、审计措施已通过静态扫描或渗透测试。
实践提示：在项目初期为每个边界分配一个唯一 ID（如
BOUNDARY-ORD-001），并在代码注释、监控指标、测试报告中引用该 ID，便于追溯与维护。
# 示例：边界 ID 命名规范
BOUNDARY-{类型缩写}-{序号}
类型缩写: BIZ / TECH / RUNTIME / DATA / SEC
示例: BOUNDARY-BIZ-001 # 业务边界：订单与支付