C4系统上下文图实例：员工学习平台的边界与外部依赖

更新时间：2026年10月08日

画员工学习平台的架构图时，浏览器、数据库、人事系统和课程模块很容易被放进同一层，结果业务同事仍然不知道：平台负责什么，哪些结果要依赖别的系统。C4系统上下文图先回答这两个问题。它把一个目标软件系统作为中心，只展开直接使用它的人和与它交互的其他软件系统。

可以先用Boardmix在线架构图工具整理参与者、系统职责与关系，再考虑内部结构。下面以新员工学习平台为例，把该画的元素、应移走的细节和需要确认的依赖逐项落到图上。

先写系统职责，避免把组织边界当成系统边界

C4官方的系统上下文图说明将这一层的范围限定为一个软件系统，重点是人及其直接关联的软件系统，而不是协议、技术栈和内部实现。非技术读者也应能理解图中的关系。

本例给中心系统写一句职责：“新员工学习平台——安排入职学习计划，呈现课程入口，并汇总学习完成情况。”随后补上三个边界条件：

这些是本例的设计设定，实际项目需要由相应负责人确认。人事系统即使属于同一家公司，仍可以是学习平台边界之外的系统；“外部”在这里指目标系统之外，不等于公司之外。

先列实际需要的参与者和依赖，再逐个问：“这是使用者角色、完整软件系统，还是某个系统内部的组成部分？”本例保留两种人员角色、一个目标系统和四个相邻系统。

浏览器先移走，它是用户访问系统的客户端，不是本层要单独解释的业务参与者。学习记录数据库属于平台内部实现，移到容器层再展开。课程目录、统计报表和提醒模块是平台能力，也不应与完整的人事系统并列。

这种取舍不是说数据库不重要，而是让图保持同一抽象层级。若当前问题已经变成“提醒服务怎样读数据库”，应另画更细一层，不要不断向上下文图塞框。

连线应让读者知道关系为什么存在。本例可以采用以下六条关系；箭头方向与文字一起读，不把它们当成执行先后顺序：

“课程入口及学习结果”必须与真实集成范围相符。若实际仅跳转到课程页面，尚不能取得完成情况，就删去“学习结果”，并记录这个能力缺口。不能因为业务希望自动汇总，就在图里假设依赖已经提供。

同样，“提供员工信息”没有说明传输方式。现阶段未知是定时导入还是接口读取，可以先保留业务关系；不要为了让图显得专业，随意补协议、实时频率和供应商名称。后续设计确定后，再在适合的技术图或接口文档中记录。

布局上，两个人员角色放在左侧，中心系统居中，相邻系统分布在右侧与下方。让常读的关系尽量短，优先移动框避免交叉；每个框标明名称、类型和一句职责。图例区分目标系统、人员和相邻系统，不能只靠颜色表达类型。

沿人事系统到学习平台的关系检查：在职状态来自哪里，哪个团队确认字段含义，接收延迟是否影响权限判断。上下文图只需暴露这条责任关系；账号停用、访问控制和同步时机还需要专门设计。不能把“身份验证成功”理解为用户一定有权继续访问。

如果平台只保留课程入口，替换主要影响入口映射；如果它还汇总学习结果，就需要确认结果标识、完成口径及历史记录如何衔接。图上同一条关系里的两个用途，可能产生不同的迁移工作。将未确认事项贴在关系旁，交给课程集成负责人核对。

本例邮件承担提醒，不能从“存在依赖”直接推断“整个系统无法学习”。讨论需要回到设计：用户能否主动查看计划，提醒失败如何处理，是否存在其他必须通过邮件完成的步骤。若发现首次访问还必须依赖邮件邀请，应更新职责与关系，而不是把事实留在口头补充中。

这些问题不要求在一张图里画完异常流程。它们帮助确认依赖是否真实、用途是否完整、边界是否有争议。详细时序、故障恢复和数据处理留给后续图与说明。

在图旁留一小块记录：系统范围、负责人、版本日期、尚未确认的关系。比如“课程完成结果接口待课程方确认”，比一条看似已经上线的箭头准确。正式汇报前请培训、身份、人事和研发人员分别检查与自己相关的职责，不仅检查图是否美观。

如果大家已经能回答“谁使用平台、平台负责什么、依赖谁提供什么”，这一层就完成了任务。下一步再按系统架构图的分层绘制方法展开应用、服务和数据存储，保持中心系统的名称与边界前后一致。以后增加新的软件依赖时，更新这张上下文图；只更改内部模块时，通常应先检查对应的下层图。