TOGAF架构实践：用UML绘制软考答题平台Phase A业务图

在我们之前的系列文章介绍了如何使用面向对象分析与设计方法来构建答题系统。今天，我们将换个角度，使用TOGAF的ADM（架构开发方法），从零开始一步步构建一个软考答题平台。

可能有些朋友对TOGAF还不熟悉，但如果你想向系统架构师转型，这是一个绕不开的框架。简单来说，它是企业架构的“施工蓝图”。了解它是什么以及如何运用至关重要。许多大公司，如IBM、华为，都在使用这套框架，考取TOGAF认证对职业发展也颇有助益。

背景介绍完毕，让我们回到正题。想象一个典型的工作场景：老板或业务部门提出了一个明确的需求，例如“将现有的答题系统升级为专业的软考平台”。团队一听，觉得目标清晰，于是立刻着手进行技术设计——分库分表、规划微服务、选型Vue3和SpringBoot。

然而，埋头干了两个月后，问题开始浮现。产品经理提出要支持AI智能批阅，运营团队要求题库能按机构分成不同版本，老板则关心如何与公司未来的培训平台打通。这时你才猛然发现，最初那张画得再漂亮的技术架构图，可能从第一天起方向就偏了。

问题出在哪里？我们过早地跳入了“怎么做”的技术深水区，却忘了先花半小时，在水面上把“为什么做”和“到底要做什么”的地图画清楚。

今天，我要分享的就是这套 “先画图，再动手”的实战方法，利用TOGAF框架和UML图，确保你的项目从起点就不跑偏。

01 先认识一下TOGAF：不是技术，而是工程思维脚手架

上图展示了TOGAF ADM的核心阶段。你可能觉得TOGAF理论高大上，落地困难。其实不然，它本质上是一套企业架构的蓝图和施工管理方法，指导你如何将公司的业务、技术、数据和应用高效、稳健地整合在一起。例如，当公司面临数字化转型，但系统混乱、业务与科技团队沟通不畅时，TOGAF就能派上用场。

TOGAF就像建造一栋数字化大楼的完整蓝图和项目管理手册：

1. 它不是水泥或钢筋：它不规定你必须使用Spring Boot还是Go，Redis还是MongoDB。
2. 它是建筑师的设计流程：它告诉你盖楼前需要先勘测地质、确认需求、设计结构、规划施工步骤。

它的核心价值，在于提供了一套名为ADM的九步法。这套方法像一份详细的菜谱，分阶段进行：从理解业务目标开始，经过设计、实施，到最终的治理，一步步推进，避免拍脑袋决策。ADM强制我们按顺序思考，确保不遗漏关键环节，并让所有参与者（业务方、产品、架构师、工程师）能够使用同一套“语言”和“图纸”进行沟通。最终目标是让技术真正服务于业务战略。

为什么你需要这套脚手架？

1. 告别一上来就画技术框图：强制你先理解业务目标和范围。
2. 避免架构漂移和重复造轮子：确保新系统的各个部分协调一致。
3. 让复杂决策变透明：“为什么这么选型？”“为什么先做这个？”答案都清晰地写在架构文档里。
4. 管理干系人预期：用业务架构图、流程图把需求可视化，减少不必要的争论。

02 文章规划：基于TOGAF的一次实践

这个系列，我们将以TOGAF ADM为主线，继续以手边的答题系统为案例，演示如何将一个想法落地为可持续的系统。

篇章	核心主题 (TOGAF ADM对应阶段)	要解决的关键问题	核心UML图
1. 总体规划 (本篇)	确立项目架构愿景与范围 (Phase A)	我们到底要去哪？边界在哪？	用例图、组件图、四象限图
2. 梳理航路	设计核心业务架构 (Phase B)	业务是怎么运转的？	活动图、业务组件图
3. 绘制甲板	规划应用架构与服务 (Phase C-应用)	系统由哪些‘软件积木’组成？	组件图、序列图
4. 规整货舱	设计数据架构与演进 (Phase C-数据)	数据怎么存、怎么流？	类图、ER图
5. 制作引擎	设计技术架构与部署 (Phase D)	用什么技术实现？怎么部署？	部署图、技术组件图
6. 制定航线	架构迁移规划与实施路线图 (Phase E, F)	怎么从旧系统平稳迁移？	路线图、甘特图
7. 全程护航	安全与运维架构设计 (贯穿各阶段)	怎么保证安全且不迷路？	安全控制图、监控架构图

背景和路线图介绍完毕。现在，让我们正式启航，进入决定成败的第一步：勾勒蓝图（Phase A）。

03 用UML画出你的航海图

共识不是聊出来的，是画出来的。想象一下这个场景：你和产品经理、业务方开会讨论需求，大家各执一词，陷入僵局。这时，你打开绘图工具说：“我们先一起把谁关心什么画出来。”

图一画完，争论的焦点瞬间清晰。这就是UML在架构愿景阶段的威力——它把模糊的讨论，变成可视化的锚点。

3.1 用【用例图】与【干系人矩阵】厘清谁要什么

1. 主用例图：划定系统边界与核心服务对象
   这张图回答：我们这个系统为哪几类人服务？为他们提供什么核心价值？

绘图实战要点：

• 矩形框：明确标出系统边界。这就是在直观地定义项目范围。
• 小人图标：代表参与者（Actor），即核心干系人角色。注意是角色，不是具体职位。
• 椭圆：代表用例（Use Case），即系统提供的、可观测的价值服务。用动词短语描述。
• 连线：表示“谁需要什么”。当开发同事问“这个功能给谁用？”时，这张图就是答案。

2. 干系人关注点矩阵：对齐期望，管理冲突
   光有图不够，我们需要把每个干系人背后的诉求和担忧表格化。可以直接在绘图工具里用表格组件画出来，贴在用例图旁边。

干系人角色	核心关注点（他们想要什么）	潜在顾虑（他们怕什么）	架构设计启示
考生	题目权威、答案准确；学习路径智能、省时间；进度清晰有成就感。	题目有错、刷题卡顿；练习没有针对性。	性能、准确性、推荐算法是核心
系统管理员	后台操作高效、稳定；用户问题能快速排查。	后台复杂难用、出问题背锅。	后台UX、监控告警、日志溯源必须到位
批阅员	批阅任务分配公平、界面友好；能批量操作、有参考答案辅助。	任务积压、界面难用效率低。	需设计批阅工作流、任务队列
业务负责人	快速上线验证市场；能灵活扩展新题库/模式；数据能看，能决策。	投入大见效慢、做成铁板一块没法改。	架构扩展性、数据分析、项目分期是关键

这两步的实战输出物：一张贴在项目Wiki首页的 干系人与核心用例图 ，并附上旁边的关注点表格。所有新成员加入，看5分钟就能明白项目为谁而做。

3.2 一句话说清我们要造什么样的船

愿景不是功能的堆砌，而是一句面向未来的、有感染力的陈述。它描述 成功后世界会变成什么样。

1. 差的愿景：做一个支持多题库、多角色、能刷题能考试的软考系统。（这只是在复述需求）
2. 好的愿景：打造一个权威、智能、个性化的软考一站式备考平台，成为软考考生信赖的备考伙伴和培训机构高效的内容与教学管理工具。

看出区别了吗？好的愿景有情感、有价值主张、有服务对象。它为我们后续的所有技术决策提供了价值锚点。

基于我们的需求，可以定义本项目的架构愿景：

将当前单一维度的答题工具，演进为一个以多题库体系为核心、覆盖‘学-练-考-评’全流程、具备扩展性的专业软考知识服务平台，支撑业务从单一产品向多元化、B2B2C模式拓展。

3.3 用【四象限图】划定范围——明确什么在船上，什么在岸上

范围不清，是项目范围蔓延和团队内耗的根源。TOGAF在这一步要求我们明确 本次迭代，我们做与不做 的界限。

根据需求，我们可以用一张简单的四象限图来框定核心范围：

1. 第一象限（核心范围 × 核心能力）：必须保质保量完成的“心脏”部分。核心答题与学习流程和 管理后台是项目的根基。
2. 第二、四象限（重要但本次不做/非核心）：像 AI智能批阅 和 多租户管理 属于战略能力，但复杂度高。TOGAF的思路是：在架构上预留接口，在实施上分步进行。本次可以在数据模型、接口设计上为它们留好“插座”，但不实现具体功能。
3. 第三象限（直接砍掉）：社交功能 直接排除，避免干扰主航道。

同时，必须明确 约束条件（在TOGAF中称为约束和假设）：

1. 技术约束：必须兼容微信小程序，后端需基于现有Java技术栈演进。
2. 数据约束：需要从原系统题库平稳迁移数据。
3. 非功能约束：关键API响应时间 < 500ms，支持1000+并发用户。

3.4 用【组件图】描绘业务与技术如何衔接（架构愿景图）

这是Phase A的高阶产出，也是TOGAF的精髓——展现 业务目标如何驱动IT建设。我们使用UML组件图来绘制，它最适合描述系统的高层功能模块及其协作关系。

绘图要点：

1. 两个色块区域：清晰分离 业务领域 和 平台能力（系统） 。这是我们想传达的第一层信息：业务是核心，系统是赋能者。
2. 业务侧：不是功能列表，而是业务角色和他们执行的核心业务流程。
3. 系统侧：不是技术模块（如“用户服务”），而是支撑业务流程的能力组件。
4. 依赖关系箭头：方向至关重要！ 箭头从业务流程指向IT能力，表明 业务依赖系统能力来实现 。这固化了业务驱动的架构思想。
5. 命名：使用业务语言（如“学习引擎”、“工作台”），而非技术语言（如“Spring Boot微服务”、“Redis缓存”）。

这张图的目的是“说人话”，让所有人都能看懂。当业务方质疑某个系统投入时，你可以指着图解释：“看，您要求的‘智能评阅’流程，依赖于我们正在构建的‘批阅工作台’能力。没有它，这个流程就跑不通。” 所有的讨论都将基于这幅可视化的共识图展开。

04 实战工具和流程推荐

聊了这么多理论，让我们落地到实际操作。当你准备启动一个新项目时，可以参照以下清单来执行Phase A。

4.1 工具准备

任选其一：Draw.io (免费、在线、易用)、Visual Paradigm (功能强大)、甚至 PPT/Excalidraw 都可以。核心要求是能快速绘制出表达清晰、易于传播的图表。当然，也有专业的企业架构软件（如Sparx Systems的Enterprise Architect，简称EA），但入门稍有难度。

4.2 干系人协作工作坊（约1小时）

1. 画系统边界与用例（30分钟）：
   • 打开绘图工具，画一个大矩形作为系统边界。
   • 提问：“我们这个系统主要服务哪几类人？” 将代表角色的小人画在框外。
   • 提问：“每一类人最想从系统里完成的最主要的一件事是什么？” 将椭圆（用例）画在框内，并用线连接对应的角色。
   • 共识焦点：确认有没有漏掉重要角色？用例描述是否准确反映了核心价值？
2. 填充干系人关注点表格（15分钟）：
   • 基于刚才识别出的角色，快速协作列出他们的核心诉求（要什么）和主要担忧（怕什么）。
   • 共识焦点：我们的设计优先级是否回应了这些核心关注点和顾虑？
3. 共创业务-系统愿景图（15分钟）：
   • 新建一页，画出左右或上下两个区域。
   • 左侧/上方：写下我们讨论的业务领域和核心流程（可采用便利贴式的头脑风暴）。
   • 右侧/下方：思考：“那么，我们需要建设什么样的IT能力来支撑这些流程？” 列出4-6个核心能力块。
   • 画出从“业务流程”指向“IT能力”的依赖箭头。
   • 共识焦点：这张图是否描绘出了我们想达到的未来状态？能力块是否覆盖了所有核心流程？

4.3 产出物

将最终确认的三样东西——用例图、干系人关注点表格、业务-系统愿景图——合并到一份一页纸的《架构愿景说明书》中。做到这一步，你已经成功完成了系统架构设计的第一步，为项目的成功奠定了坚实的地基。这份文档也是后续与团队对齐和进行详细 系统架构设计 的重要输入。

05 总结

当然，用 UML 画愿景图并非唯一范式，重点在于创造一个所有干系人能共同指着一幅图进行讨论的“场域”。在这个场域里，分歧无处藏身，共识自然达成。此外，UML也是我们软件开发人员最熟悉的建模语言之一，上手非常容易。

TOGAF不是束缚手脚的教条，而是让你在复杂项目中，思考更全面、沟通更顺畅、决策更稳健的一套“心法”。Phase A产出的这四张图（用例图、干系人矩阵、四象限图、业务-系统愿景图），就是这套心法的第一个实战成果。

请记住这个核心原则：在深入讨论“怎么做”之前，先花1小时搞清楚“为什么做”和“做什么”。这1小时的前期投资，极有可能避免你未来数十甚至上百小时的返工和内耗。

---

本文讨论的 TOGAF 和 UML 建模方法，是构建清晰、可维护软件系统的关键。如果你想深入学习更多企业架构、设计模式等相关的 技术文档 与实战案例，欢迎持续关注 云栈社区 的更新。