企业官网建设流程全解析

1. 系统分析与设计到底在解决什么问题

系统分析与设计这门东西，最尴尬的地方在于：考试的时候背得滚瓜烂熟，一到真做项目就全还给老师了。我前后参与过七八个从零到一的后台系统，也接手过几个别人留下的半成品烂摊子，越往后越发现，真正决定一个系统能不能活得久、改得动的，往往不是用了什么框架、什么中间件，而是分析和设计阶段有没有把该想清楚的事情想清楚。框架可以换，数据库可以迁，但如果一开始业务边界就是糊的、模块依赖是乱的，后面每加一个需求都像在拆迁现场上盖楼。

这篇内容我想按自己实际干活的顺序来梳理一遍，不搞那种名词解释大礼包，而是把"为什么这么选""什么场景用什么图""哪里最容易翻车"讲透。适合两类人看：一类是正在学这门课、被 UML 和 DFD 绕晕的学生，另一类是已经工作两三年、发现自己天天写代码但说不清楚系统该怎么拆的开发者。前者可以把它当成知识点的落地注解，后者可以当成一次自查清单。

1.1 从"能跑就行"到"改得动"的分水岭

刚入行那会儿我的判断标准特别朴素：功能点了能出结果，就算完成。后来系统慢慢长大，问题全冒出来了——同一个"订单状态"，订单模块里叫 status，结算模块里叫 orderState，报表里又有第三种叫法；改一个字段的校验规则，要在五个地方同步改，漏一个就出线上问题。这时候我才明白，系统分析与设计真正的交付物不是代码，而是"共识"：对边界的共识、对数据含义的共识、对交互时序的共识。

有句话我经常跟新人说：代码是写给人看的，顺便给机器执行。一个系统能跑，靠的是机器执行；一个系统能改，靠的是人看得懂。系统分析与设计就是那个"让人看懂"的过程——它把脑子里的模糊想法，翻译成一张张图、一份份规约、一套套接口定义，最后才落到代码上。

所以这门知识的价值不在于图有多漂亮，而在于它逼你提前回答那些你本能想跳过的问题：这个功能谁来触发？失败路径怎么办？数据从哪来、到哪去、中间存不存？两个人同时操作同一条记录会怎样？这些问题在编码阶段才发现，返工成本是设计阶段的十倍不止。

1.2 分析、设计、架构三者的边界与交付物

很多人把这三个词混着用，其实它们关注的东西不一样，交付物也不一样。我用一个装修的类比来说明：分析是问清楚"你要几间房、做饭多不多、有没有老人"，设计是画水电图和家具布局图，架构则是决定"承重墙能不能动、走明线还是暗线、地暖还是暖气片"。

分析阶段的产出，核心是需求规约和业务模型。它回答"要做什么"，不碰"用什么技术做"。这里的关键动作是把用户嘴里的"我想要一个方便管理的东西"拆成一条条能验证的条目。设计阶段的产出是模块划分、接口定义、数据结构、交互时序，回答"怎么做"。而架构是设计里层次最高的那部分决策，回答"整体的骨架长什么样、关键的非功能需求靠什么保证"。

表里我把三者的区别列清楚，这个对照在面试和实际评审里都用得上：

这个边界不是死板的。实际项目里迭代很快的时候，分析和设计会交替进行，但逻辑上一定是先搞明白问题，再决定方案。我见过最典型的翻车就是跳过分析直接设计：团队花两周把技术架构画得漂漂亮亮，结果业务方一句"我们的审批流程其实是三级不是两级"，整套设计推翻重来。

2. 需求分析：把所有"我觉得"翻译成可验证的条目

需求分析是整门课里最不"技术"、但最容易决定成败的部分。它不需要你懂什么高深算法，需要的是把模糊语言翻译成精确语言的能力。我总结下来，翻译的过程分三步：先分清需求类型，再选择合适的建模方式表达，最后用可追溯的方式管理起来。

2.1 功能性需求与非功能性需求的拆解方法

功能性需求好理解，就是"系统要提供哪些行为"，比如"用户可以按手机号搜索订单"。它天然适合用动词短语来描述：谁，对什么，做了什么，得到什么结果。

真正容易被忽略的是非功能性需求，也就是那些描述"做到什么程度"的要求。它不写出来，系统也能跑，但一到真实压力下就崩。常见的几类我列一下，这个清单我每次做需求梳理都会过一遍：

• 性能：响应时间、吞吐量、并发用户数。别写"要快"，要写"95% 的查询请求在 500ms 内返回"。
• 容量：数据量级、增长速率、保留周期。是十万条还是十亿条，设计完全两回事。
• 可用性：允许的停机时间、降级策略、故障恢复时间。
• 安全性：认证方式、权限粒度、敏感数据的处理要求。
• 可维护性：日志规范、监控指标、配置化程度。
• 兼容性：需要支持的客户端版本、浏览器、数据格式。

拆解的时候有个技巧：把每条非功能需求都绑定到一个可测的指标上。我见过一份需求写着"系统应具备良好的扩展性"，评审时我问"良好是什么标准"，没人答得上来。后来改成"新增一种支付渠道的接入工作量不超过 3 人天，且不需要修改订单核心逻辑"，这条需求立刻就变得可验证、可验收了。

注意：非功能需求如果写成形容词，等于没写。评审时凡是看到"良好""高效""友好"这类词，都要当场追问成具体数字或具体场景。

2.2 用例图、用例规约与用户故事的取舍

表达需求有三套主流工具：用例图、用例规约、用户故事。它们不是互相替代的关系，而是粒度不同。

用例图解决的是范围和角色问题。它一眼就能看出系统有哪些参与者、每个参与者能触发哪些用例、哪些用例被多个角色共享。我在项目启动会上必画一张，就为了跟业务方确认"这个功能到底有没有这个人用"。画的时候注意两点：一是参与者是角色不是具体的人，二是用例是完整的业务目标而不是单个操作步骤。"登录"算不算用例有争议，我倾向于把"登录"当成"使用系统"这个用例的前置条件，除非它本身有复杂的业务价值。

用例规约是把一个用例写细，通常包含前置条件、主成功场景、扩展场景、后置条件。很多人嫌它啰嗦，但扩展场景才是真正值钱的地方。主流程谁都会写，异常路径才是 bug 的温床。举个例子，"提交订单"的主流程五步写完，扩展场景却可能有十几条：库存不足怎么办、优惠券失效怎么办、支付超时怎么办、重复提交怎么办。我习惯在写规约时强迫自己至少列五条扩展场景，列不满就说明还没想透。

用户故事则是敏捷里常用的轻量表达，格式是"作为某角色，我希望做某事，以便获得某价值"。它的优势是贴合用户视角，劣势是容易漏掉非功能和边界。我的做法是：用用户故事做需求池管理，用用例规约做详细设计前的补充。两者配合，既保持了灵活性，又不至于在边界情况上掉链子。

2.3 需求可追溯矩阵与评审

需求做完不是结束，而是管理开始。需求可追溯矩阵（Requirements Traceability Matrix）听着很重，其实就是一个表，把需求 ID 和它的来源、对应的设计模块、对应的测试用例连起来。

它的价值在变更时体现得淋漓尽致。线上出了个 bug，通过矩阵能立刻反查：这条逻辑对应哪条需求、当初是谁提的、相关测试用例有没有覆盖。我做重构项目时，矩阵帮我快速圈出了"哪些需求其实已经没人用了"，直接砍掉三成历史包袱。

评审环节我建议分两轮。第一轮是业务评审，只问"这是不是你要的"，不谈技术；第二轮是技术评审，只问"这个能不能做、有没有歧义、边界是否完整"。两轮混在一起开，业务方会被技术细节带偏，技术方会被业务语言干扰，效率极低。

3. 建模工具箱：什么场景用哪张图

建模是系统分析与设计里最容易"为画而画"的部分。教科书上动不动列出十几种图，实际工作中真正高频使用的也就五六种。我的原则是：图的目的是沟通，不是炫技；一张图讲不清的事，往往不是图不够，而是问题没拆开。

3.1 数据流图与ER图：结构化分析的看家本领

数据流图（DFD）适合描述"数据在系统里怎么流动"。它有两个层次：顶层图把整个系统当成一个黑盒，只画外部实体和输入输出；逐层分解图则把加工过程拆开，一直到足够细为止。我常用它跟业务方梳理流程，因为业务人员对"单据从哪来、经过谁的手、变成什么"这种叙述天然有感觉。

画 DFD 有个铁律：父图和子图的数据流必须平衡。父图里进出一个加工的数据流，在子图里必须都能找到对应。我刚学的时候老犯这个错，父图画了三个输入，子图只画了两个，一看就是漏了。这个平衡检查是最有效的自查手段。

ER 图则是数据建模的基础，描述实体、属性和联系。它和后面的表结构设计直接对应，所以我在做 ER 图时会顺便把三个信息标记上：主键、是否可空、基数（一对一、一对多、多对多）。多对多关系在物理设计时必须拆成中间表，这一点在 ER 图上提前标出来，能省掉后面很多返工。

DFD 和 ER 图的关系可以这样理解：DFD 关注"动"，数据怎么流转；ER 图关注"静"，数据怎么存。两者结合，一个业务系统的面貌就基本清晰了。

3.2 UML 静态视图：类图、对象图、包图

面向对象方法里，类图是最核心的静态视图。它描述类、属性、方法以及类之间的关系。关系有六种：依赖、关联、聚合、组合、泛化、实现。很多人画类图只画关联和泛化，但其实聚合和组合的区分在领域建模里非常重要，因为它决定了生命周期归谁管。

举个实际例子：订单和订单项是组合关系，订单没了，订单项必须跟着消失；而订单和客户是关联关系，订单删了客户还在。这个区别直接影响数据库的外键设计和级联删除策略。我在代码评审时经常用这个点考人：如果订单和订单项画成了聚合，那删除订单时订单项该不该保留？想清楚这个，设计就清楚了。

对象图是类图的实例快照，实际用得不多，主要在解释复杂数据结构时用。包图用来表达模块分组和依赖关系，在架构层面的作用更大。我习惯用包图来做依赖方向的自查：画出来之后看有没有循环依赖，有的话说明模块划分出了问题，得回去重新切。

3.3 UML 动态视图：时序图、活动图、状态机图

动态视图描述系统运行时的行为，三张图各有分工。

时序图表达对象之间按时间顺序的消息交互，是做接口设计和联调时最实用的图。我通常会在设计一个新接口时画一张简化的时序图，标清楚调用方、服务方、数据库、缓存之间的交互次序。很多并发问题就是在这个阶段被发现的：比如先查缓存再查数据库还是反过来、失败时要不要回滚、幂等键放在哪一层。

活动图表达业务流程和控制流，适合描述有分支、并行、循环的复杂流程。审批流、状态流转这类需求，用活动图比用文字描述清楚十倍。

状态机图专门描述单个对象的状态变迁。订单、工单、审批单这类有明确状态的生命周期对象，我都建议画一张。它的关键价值在于逼你把所有非法跃迁堵死：一个"已取消"的订单能不能再变成"已支付"？从状态机图上一眼就能看出有没有漏掉守卫条件。这类 bug 在生产环境特别难查，因为它往往是数据被人为改坏或者并发导致的。

3.4 建模的"够用"原则与常见画错点

我见过太多团队在建模上走两个极端：要么完全不画图，全靠口头对齐；要么画了几十张精细到属性的图，结果没人看，改代码时图早就过期了。

我的建议是按需建模，够用即止。判断标准很简单：这张图能不能帮你在评审时少吵一次架、在编码时少返一次工？能，就画；不能，就是自嗨。

常见的画错点我整理成一张速查表，都是在真实项目里踩过的：

心得：图是活的。我习惯在图旁边写一个"最后更新日期 + 对应代码分支"，一旦发现图跟代码对不上，要么改图要么删图，绝不留下过期文档污染后来人的判断。

4. 从分析到设计：架构与详细设计怎么落地

分析做完，接下来是把"要做什么"翻译成"怎么做"。这一步的难点不在于会不会用某个框架，而在于决策的取舍：分层分几层、数据要不要冗余、接口同步还是异步、缓存加在哪一层。每一个选择都有代价，关键是知道自己放弃了什么。

4.1 分层与依赖方向

分层是最基础也最有效的设计手段。经典的四层是：表现层、应用层、领域层、基础设施层。它解决的核心问题是依赖方向必须单向，也就是上层依赖下层，下层不知道上层的存在。

为什么这点这么重要？因为依赖方向决定了修改的影响范围。如果领域层反过来依赖了表现层，那你改一个接口参数，可能要动到业务核心逻辑。我接手过一个项目，业务逻辑里直接 new 了 HTTP 请求对象，导致这部分逻辑完全没法单元测试。这就是依赖方向反了。

实际操作时，领域层需要通过接口访问数据库、消息队列这些外部资源，而不是直接依赖具体实现，这就是依赖倒置的用法：接口定义在领域层，实现在基础设施层。这样领域层保持纯净，外部资源可以随时替换。

这张表我贴在自己电脑旁边，写代码前扫一眼，能省掉很多"这行代码该放哪"的纠结。

4.2 数据库设计：范式与反范式的取舍

数据库设计是详细设计里最考验功力的部分。教科书强调三范式，但真实系统里到处是反范式。理解两者为什么并存，比背范式定义重要得多。

范式化的核心目的是消除冗余、保证一致性。同一份数据只存一处，更新时就不会出现多份不一致。所以涉及频繁变更、对一致性要求高的核心数据，我坚持范式化设计。

反范式则是为了查询性能和实现简单。比如订单表里冗余一个客户名称，虽然客户改名后历史订单会显示旧名字，但如果业务上本来就要求"订单快照"，这个冗余反而是正确设计。又比如报表统计，把计算结果预计算存下来，用空间换时间，是常见做法。

我的判断方法是问三个问题：这份数据变更频率高不高？不一致会造成业务损失吗？查询压力和写入压力哪边更大？三个问题答完，范式还是反范式基本就定了。

索引设计也要在详细设计阶段定下来，而不是等线上慢了再加。原则是：为查询条件建索引，为排序字段考虑联合索引，写多读少的表要克制索引数量。索引不是越多越好，每个索引都会拖慢写入并占用空间。

4.3 接口契约与异常路径设计

接口设计最容易犯的错是只管成功路径。一个健壮的接口契约，至少要定义清楚四件事：入参的校验规则、成功返回的结构、业务失败的返回约定、系统异常的处理方式。

我见过太多接口，成功时返回{code:0, data:...}，失败时有时返回{code:1, msg:...}，有时直接抛 500，前端根本没法统一处理。正确做法是约定一个统一的响应外壳，业务错误和系统错误分层处理。业务错误（如库存不足）是预期内的，用明确的错误码返回；系统错误（如数据库连接失败）是不可预期的，走异常通道并记录日志。

// 统一响应结构示例 public class Result<T> { private int code; // 0 成功，非 0 为业务错误码 private String message; // 面向调用方的可读信息 private T data; // 成功时的业务数据 public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 0; r.data = data; return r; } public static <T> Result<T> fail(int code, String msg) { Result<T> r = new Result<>(); r.code = code; r.message = msg; return r; } }

错误码的设计也有讲究。我习惯按模块分段：1000 段是用户模块，2000 段是订单模块，以此类推。这样日志里一看到错误码就知道大概是哪块出的问题，排查效率高很多。面向用户的提示要友好，面向开发者的日志要详细，两者分开，不要混在一起。

4.4 设计模式的落点

设计模式在系统分析与设计里经常被过度神化，好像不用几个模式就不够专业。我的观点很明确：模式是解决问题的结果，不是设计的目标。先有痛点，再想模式。

举几个真实的落点。策略模式适合处理"多种算法可替换"的场景，比如不同支付渠道的对接，每个渠道的实现细节不同，但对上层暴露统一接口。工厂模式适合对象创建复杂、需要集中管理的场景，比如根据类型创建不同的消息处理器。观察者模式适合一对多的状态通知，比如订单状态变化后需要通知库存、积分、消息三个模块。

反面案例也说一个：我见过有人为了"解耦"，给每个 Service 都套了一层接口加一层实现，结果每个接口只有一个实现类，改个方法要跳三次。这不是解耦，是增加阅读成本。只有当存在真正的多实现、多变化点时，抽象才有价值。

5. 常见问题与排查技巧实录

前四部分讲的是"应该怎么做"，这一部分讲讲"实际会出什么岔子"。系统分析与设计的问题很少是技术难题，更多是沟通、节奏和管理层面的。

5.1 需求变更与范围蔓延

需求变更是常态，怕的是一边开发一边无限加需求。我应对的经验是把变更显性化：任何需求变更都记录在案，标注影响范围（涉及哪些模块、需要多少工时、会影响哪条已有需求），然后让决策者明确拍板"做还是不做、这次做还是下次做"。

范围蔓延最隐蔽的形式是"顺便"。开发过程中有人说"顺便把这个也加上吧"，听起来工作量很小，但每个"顺便"都会带来测试、文档、兼容性的连带成本。我的做法是设置一个变更缓冲，小改动攒到一起，按批次处理，而不是零散插入当前迭代。

还有一个技巧：区分"必须满足"和"可以协商"。需求评审时把每条需求标注优先级，核心路径必须做，锦上添花的功能排后面。这样资源紧张时砍什么一目了然，不会砍到关键功能上。

5.2 图表与文档的实际用途

图表过期是团队协作里的慢性病。我的解决方案是把图放进代码仓库，和代码一起评审。改一个核心接口，对应的时序图必须同步更新，否则评审不通过。这比单独维护一份文档有效得多，因为文档一旦脱离工作流，就注定被遗忘。

另一个思路是少而精。一个中型系统，我通常只维护这几份图：一张整体架构分层图、一张核心领域模型类图、三到五张关键流程时序图、一张订单类的状态机图。其余细节交给代码和注释。图少了，维护成本低，大家才愿意更新。

5.3 高频问题速查表

我把这些年被问得最多、也踩得最狠的问题整理成一张表，方便快速对照：

这张表我建议打印出来贴在工位上，遇到问题先对照，能解决一大半的日常困惑。

6. 一些个人体会

做系统分析与设计这些年，我最大的感受是：这门功夫的进步不体现在画出多复杂的图，而体现在能提前预判多少坑。刚开始我总是急于进入编码，觉得画图是浪费时间；后来被返工教训多了，才慢慢养成"先把问题想清楚再动手"的习惯。现在我做一个中等规模的功能，通常花两成时间梳理需求和建模，剩下八成才是设计和编码，但整体交付反而比以前快。

如果让我给正在学这门知识的人一条建议，那就是：找一个小而完整的真实需求，从需求分析一路做到表结构设计，中间不要跳过任何一步。哪怕只是一个图书借阅或者会议室预订的小系统，完整走一遍，比你背十遍 UML 语法都有用。理论只有在被应用过一次之后，才会变成你自己的东西。

最后分享一个我一直在用的自检习惯。每次设计完一个模块，我会问自己三个问题：这个模块的职责能不能用一句话说清？它依赖了谁、谁又依赖了它？如果业务规则明天变了，我需要改几个地方？这三个问题答得干脆，设计基本就是合格的；答得含糊，那就说明还有地方没想透，得回去重新拆。