02 核心概念与架构过程

输入“/”快速插入内容

02 核心概念与架构过程

用户5909

用户4247

用户2312

用户3028

6月2日修改

💡

一句话框架：软件架构不是方框图本身，而是用高层设计决策组织系统的重要元素、外部可见属性及其关系，从而平衡利益相关者诉求并控制风险。​

三个容易混淆的词

概念

关注点

答题关键词

Structure 结构

元素及静态关系

组成、连接、层次

Architecture 架构

关键结构加运行关系、属性与演进约束

高层、关键决策、难以更改

Design 设计

从高层到细节的全部方案活动

架构设计是设计中的高抽象层环节

为什么架构重要

•
质量基础：促进或阻碍性能、可用性、安全性、可修改性。​

•
早期约束：服务边界、通信和部署方式越晚改越贵。​

50%

•
沟通媒介：让用户、管理者与开发团队讨论同一结构。​

•
复用抽象：成熟决策可迁移到同类系统。​

50%

架构师职责：不是只画图

职责

实际含义

典型问题

协调利益相关者

在用户变化诉求与开发成本、可维护性之间达成妥协

哪个质量目标优先？

软件工程能力

用成熟实践组织设计、实现与验证

方案如何实施？

技术判断

理解选型影响而非追逐技术名词

选择会绑定哪些约束？

风险管理

识别早期决定失败的代价并准备缓解方案

最贵的失败点在哪里？

4+1 视图：从不同角度看同一系统

画板

视图

回答的问题

记忆钩子

逻辑视图

系统主要职责和对象如何组织

做什么

进程视图

运行时并发、交互与通信如何发生

怎么跑

物理视图

软件元素如何部署到硬件/节点

跑在哪

开发视图

代码模块和开发组织如何安排

怎么造

用例 / 场景

如何用实际需求贯通各视图

为什么这样看

📝

简答题写法：先写“视图用于隐藏不相关信息、突出关注点”，再列出四个视图的职责，最后说明 use case 串联并验证这些视图。​

画图题示例：4+1 视图具体怎么画

画板

📝

UML 落笔原则：先用用例图确定一个关键场景作为“+1”，再围绕它分别画逻辑视图的类图、开发视图的组件图 / 包图、进程视图的时序图 / 通信图、物理视图的部署图；每张 UML 图都标出与该用例对应的元素、关系与验证点。​

视图

图中具体画什么

UML 图型

答题标注

+1 场景

Actor“学生”完成“选课并支付”的主流程，可补登录/支付失败扩展场景​

Use Case Diagram​
用例图​

作为四视图追踪起点

逻辑视图

Course、Enrollment、Payment 等领域类、职责和关联

Class Diagram​
类图​

回答“系统做什么”

开发视图

Web UI、Enrollment Module、Payment Adapter、Repository 等代码单元依赖

Component / Package Diagram​
组件图 / 包图​

回答“代码怎么组织”

进程视图

学生请求经 Gateway、选课服务、支付服务、消息队列的运行时交互​

Sequence / Communication Diagram​
时序图 / 通信图​

标性能与可用性验证点

物理视图

客户端、负载均衡、应用容器、数据库与消息节点的部署映射​

Deployment Diagram​
部署图​

标冗余与故障隔离

1.
选场景：先把题目中的核心用户任务写成一条可执行场景，例如“学生选课并完成支付”。​

2.
画 +1：画 Use Case Diagram / 用例图：放入 Actor、系统边界与“选课并支付”用例，可标注失败或退款扩展场景。​

3.
补四图：按“职责 → 代码 → 运行 → 部署”顺序补四张 UML 图：依次使用类图、组件图、时序图、部署图表达元素和关系。​

02 核心概念与架构过程​

02 核心概念与架构过程