UML实战：三张图搞懂在线教育平台的业务架构设计

在 TOGAF 的 Phase B（业务架构）阶段，我们的目标就是跳出“技术先行”的陷阱，让业务逻辑自己清晰地浮现出来。

你是否也遇到过这种情况？产品需求文档写了厚厚几十页，可开发团队拿到手里依然无从下手：前端工程师不知道按钮点击后跳转到哪个页面；后端工程师不清楚复杂的批阅流程到底如何流转；测试工程师也不确定怎样才算完成一次完整的考试闭环？

上一阶段我们画出了系统的“愿景图”，明确了要为谁、造一艘什么样的“船”。那么现在，我们就需要把船上的各个舱室如何运转、船员之间如何协作彻底搞清楚。这正是业务架构的核心——用可视化的方式，画出所有人都能看懂、能据此行动的操作手册。

今天，我们就以一个在线答题/考试平台为例，用三张 UML 图，手把手带你拆解清楚它的业务架构。这套方法能帮你和团队有效对齐认知，大幅节省后期因需求理解偏差导致的返工成本。

业务架构到底要回答什么问题？

在动手画图之前，不妨先问自己三个问题，来测试一下你对当前业务的了解深度：

1. 一个考生从注册账号到完成一次模拟考试，需要经过哪几个关键的业务环节？
2. 一道主观题从考生提交答案到最后拿到分数，中间会经过几个人、几个系统的处理？
3. 如果管理员想为系统新增一个专业方向的题库，需要配置哪些内容，又会影响到哪些已有的业务流程？

如果你无法立刻、清晰地回答这些问题，那就说明业务逻辑还没有真正“长”在你的脑子里。业务架构正是为了解决这个问题——把散落在产品、运营、技术等各方人员大脑中的业务知识，萃取、提炼并固化成为一套可视化的、可推演的业务地图。

在 TOGAF 框架中，Phase B 阶段需要产出三个核心的架构制品：

1. 业务能力地图：我们的组织或系统拥有哪些核心的“业务肌肉”？
2. 端到端业务流程：这些“肌肉”在具体场景下是如何协同工作的？
3. 业务角色与交互：在每一个环节中，具体是谁、在做什么事？

下面，我们就围绕这三点，一步步完成架构设计。

第一步：提炼业务能力——画出我们的“业务肌肉群”

业务能力（Business Capability）不是一个个零散的功能点，而是组织为了持续创造价值所必须具备的核心本领。这就像人体的肌肉群，胸肌负责推，背肌负责拉，每一块都有其明确的作用。

基于在线答题平台的核心需求，我们可以提炼出以下六大核心业务能力域，并进一步分解为具体的关键能力。

绘制要点与价值：

1. 分层展开：第一层是宏观的“能力域”（大肌肉群），第二层是关键的具体“能力”（具体肌肉）。这有助于从战略到执行的逐层分解。
2. 使用业务语言：使用“学习路径规划”而非“推荐算法服务”这样的描述。这能确保业务方和技术方在沟通时使用同一套语言体系，减少歧义。这正是让业务自己说话的关键。
3. 遵循 MECE 原则：确保各个能力之间“彼此独立，完全穷尽”。绘制完成后，一定要检查是否有能力重叠或遗漏。

这张图最大的价值在于：当业务方提出一个新需求时，你可以快速将其定位到某个需要增强或扩展的既有能力上。例如，业务提出“想增加每日学习报告推送”，你一看能力地图就知道，这是在“数据分析与决策支持”能力域下，新增一个“学习报告生成”的子能力，而非凭空创造一个全新的东西。

第二步：绘制端到端业务流程——“肌肉”是如何协同工作的？

这是业务架构设计的灵魂所在。我们重点拆解两个最核心、也最容易在开发过程中出现理解偏差的流程。

流程一：考生参加模拟考试的完整旅程（活动图）

这个流程描述了考生从进入系统到完成一次模拟考试的全过程。

活动图绘制要点：

1. 起点与终点明确：每个流程都应有唯一的开始节点和结束节点。
2. 规范使用决策节点：所有分支判断都使用菱形符号，这是 UML 活动图的标准。
3. 善用子活动区：对于“答题循环”这类重复或复杂的逻辑，用子图框起来，能让主流程的阅读体验更清晰。
4. 适时引入泳道：如果流程涉及多个角色交互，就加上泳道（Swimlane）来区分。本例主要是考生单角色流程，故未加。

这张图解决了什么实际问题？

• 给前端：明确了需要开发“考试大厅”、“考试规则页”、“考试界面”、“成绩报告页”四个核心页面及其跳转逻辑。
• 给后端：明确了需要提供“考试可用性校验”、“答案实时保存”、“客观题自动批阅”、“成绩报告生成”四个关键服务。
• 给测试：提供了从“无考试状态”到“完成考试查看报告”的端到端测试路径设计依据。

流程二：主观题批阅的跨角色协作流程（带泳道的活动图）

主观题批阅是典型的跨角色、异步协作流程，最容易产生责任不清的问题。用带泳道的活动图可以一目了然。

带泳道活动图的核心价值：

1. 责任清晰化：一眼就能看出“考生提交”、“系统分配”、“批阅员处理”每个环节是谁的职责，从根本上避免事后推诿。
2. 接口明确化：泳道之间的箭头，直观地代表了系统需要提供的接口或消息通知机制，这是后续架构设计的重要输入。
3. 引导异常思维：虽然图中主要展示的是正常流程（Happy Path），但在实际绘制时，必须考虑“批阅员超时未处理”、“双评结果差异过大”等异常分支的处理逻辑。

补充：定义业务角色与交互（业务用例图）

基于上述流程，我们可以进一步抽象出系统中涉及的关键角色及其要达成的业务目标。

请注意，这里画的是“业务用例图”（Business Use Case），而非“系统用例图”（System Use Case）。两者的核心区别在于：

• 业务用例：关注角色要完成的业务目标，例如“完成模拟考试”。
• 系统用例：关注角色与系统的具体交互行为，例如“点击开始考试按钮”、“提交试卷”。

为什么要强调这个区别？因为业务用例是相对稳定的，而系统实现方式是可能变化的。今天考生通过网页完成考试，明天可能换成小程序，但“完成模拟考试”这个业务目标不会改变。基于稳定的业务用例进行设计，系统的扩展性和适应性会更强。

进阶：绘制业务服务/能力图——从流程到可复用的“业务积木”

最后，我们可以将业务流程中反复出现、具备独立价值的环节，抽象为业务服务（Business Service）。这是连接业务架构与后续应用架构、微服务设计的关键桥梁。

业务服务图的价值：

1. 识别复用机会：例如，你会发现“考试编排服务”既被“模拟考试”流程使用，也可能被“正式考试”流程使用。
2. 指导微服务拆分：图中每一个业务服务，在未来都可能对应一个或多个独立的微服务，这为系统设计提供了清晰的边界。
3. 明确依赖关系：清晰地看到“学习路径服务”依赖于“知识点体系服务”，这直接决定了这些服务的开发先后顺序和技术依赖。

在绘制这张图的过程中，我们还可能发现新的洞察。比如，“批阅质量监控”被识别为一个独立的服务，而非“在线批阅”的一部分。这意味着我们需要在数据模型和接口设计上为其预留位置，为未来引入 AI 辅助质检等高级功能做好扩展准备。

实践清单：如何在你团队中落地？

梳理工作（建议以工作坊形式进行）：

1. 绘制业务能力地图
   • 核心问题：要实现我们的业务目标，必须拥有哪些核心能力？
   • 达成共识：这些能力是否覆盖全面？优先级如何排序？
2. 绘制核心业务流程活动图（选择1-2个最复杂的流程）
   • 从用户视角出发：当用户想做XX事时，第一步是什么？
   • 逐环节深挖：然后呢？这一步谁来做？系统需要提供什么支持？
   • 达成共识：流程图是否真实反映了业务？异常流程考虑周全了吗？
3. 识别关键业务服务
   • 核心问题：哪些步骤在不同的流程中会重复出现？
   • 核心问题：哪些能力应该被设计为独立的、可复用的服务？

产出物：

三份核心文档：

1. 业务能力地图（建议一页纸呈现）
2. 核心业务流程活动图（每个关键流程一页）
3. 业务服务目录图（建议一页纸呈现）

团队可以围绕这些产出物召开一次正式的评审会，邀请业务、产品、研发、测试各方参与。评审标准很简单：一个刚入职的新同事，仅凭这些图表，能否大致理解我们的业务是如何运转的？

日常应用场景：

• 给开发团队：业务服务图就是微服务拆分和服务接口设计最直接的输入。
• 给测试团队：端到端的活动图是设计集成测试和业务流程测试用例的最佳依据。
• 给产品经理：业务能力地图是评估新需求影响、进行需求优先级排序的框架性工具。
• 给整个团队：这些图表构成了项目“业务知识库”的核心资产，能有效对抗人员变动带来的知识流失。

需要避开的常见误区

1. 混淆系统流程与业务流程
   • 错误做法：在业务架构图中画满了“点击按钮”、“调用API接口”。
   • 正确做法：聚焦于“考生报名”、“批阅员评阅”这类业务活动本身。
2. 只画“完美路径”，忽略异常
   • 错误做法：只描绘一切顺利的理想情况（Happy Path）。
   • 正确做法：必须系统性地考虑“考试中途断网”、“批阅员临时请假”等异常和边界情况，并画出相应的处理流程。
3. 闭门造车，缺乏共识
   • 错误做法：架构师或产品经理独自画完，直接丢给研发团队。
   • 正确做法：必须与关键的业务方（领域专家）以及技术团队成员共同绘制、评审并确认，确保图纸是集体智慧的结晶，而非一厢情愿的想象。

总结

业务架构绝非纸上谈兵。它是一项至关重要的工程化活动，旨在将隐性的、碎片化的业务逻辑，显性化、系统化地提取出来，转化为团队共享、可追溯、可推演的业务蓝图。你今天为厘清业务所画的每一张图，都在为明天的项目节省大量的沟通成本，避免潜在的需求误解，并最终加速产品的开发与交付。

当你真正主导或参与完成一次完整的业务架构梳理后，你会发现自己对业务的理解深度将完全不同。下次当产品经理提出一个新需求时，你或许可以这样反问：“这个需求主要影响的是哪个业务流程？它旨在增强我们哪一块业务能力？”——这，就是架构思维的开始。

你们团队目前有清晰、共识度高的业务流程图吗？是否曾因业务逻辑不清而导致过项目返工？欢迎在云栈社区的讨论区分享你的经历与思考，我们一起看看哪些“坑”可以提前避开。