第4章系统边界与上下文

绘制系统上下文图，明确系统与外部实体的交互。

系统上下文图（System Context Diagram）是技术方案设计的起点。它用最简洁的方式界定“我们要构建什么”以及“它和谁对话”。本章将带你掌握边界划分原则、上下文图绘制方法，并通过实例理解外部实体、输入输出与依赖关系。

▲ 图4-1 订单管理系统上下文图（示例）

4.1 为什么需要系统边界？

系统边界定义了“什么在系统内，什么在系统外”。没有清晰的边界，设计会无限膨胀，需求会模糊不清。边界帮助我们：

聚焦核心职责 —— 只做系统该做的事，把外部能力委托给专业服务。
管理依赖 —— 明确每个外部交互的协议、数据格式和SLA。
控制变更影响 —— 边界内的修改不影响外部，反之亦然。

4.2 上下文图的核心元素

元素	说明	示例
核心系统	你正在设计/构建的软件系统	订单管理系统、用户中心
外部实体	与系统交互的人、系统、设备	客户、支付网关、管理员
交互流	数据或控制流的方向与内容	下单请求、支付回调、发货指令
边界线	视觉上区分系统内外	通常用矩形框或虚线区域

▲ 图4-2 系统边界与外部实体交互示意

4.3 绘制上下文图的步骤

识别主要外部实体：谁使用系统？系统依赖哪些外部服务？
定义核心系统：用一个有意义的名称概括系统（如“在线支付平台”）。
列出关键交互：每个实体与系统之间交换什么数据或指令。
绘制并验证：使用统一建模语言（UML）或简洁框图，与干系人确认。

4.4 常见错误与最佳实践

错误	后果	最佳实践
把内部模块画成外部实体	边界模糊，职责混乱	只画系统外的人、系统、设备
遗漏关键外部依赖	设计缺失，后期返工	与运维、产品一起脑暴所有交互方
交互流过于细节	上下文图变成流程图	保持“什么交互”，而非“如何交互”

▲ 图4-3 上下文图绘制流程

4.5 实战：用代码表达上下文

在技术方案文档中，除了图形，也可以用结构化文本描述上下文。例如使用 YAML 或 Markdown 表格：

# system-context.yaml
system: 订单管理系统
external_entities:
  - name: 客户
    interactions:
      - 创建订单 (HTTP POST /orders)
      - 查询订单 (HTTP GET /orders/{id})
  - name: 支付网关
    interactions:
      - 发起支付 (远程API)
      - 接收支付回调 (Webhook)
  - name: 仓储服务
    interactions:
      - 下发发货指令 (gRPC)
      - 订阅库存变更 (消息队列)

第4章 系统边界与上下文