软件架构设计

直接背诵总纲与答题模板

· heleyang
软件架构设计 期末复习
目录

# 00 直接背诵总纲与答题模板

**怎么用本页：**本页只放考前可直接背诵的总纲内容。

  • **先背答案：**优先背每题的“可直接作答”段落和最后的默写清单。

  • **再看专题：**需要理解表格、例子和画图时，跳到 02-06 对应专题页。

  • **考试边界：**三份飞书纪要已明确 AI 增强 / AI 原生 为考试后或背景介绍内容，不纳入期末考试要求。

  • **主要依据：**老师智能纪要与《扫描文档20260526_192514.pdf》（MinerU OCR）。

# 先记一条总链

# 总纲脑图：从需求到答题

**记忆方法：**先按“需求 → ASR → 设计 → 文档与评估 → 专题深化”背总路径，再把每个专题页挂到对应节点上。

总链条：

  1. 业务目标 / stakeholder concerns 产生需求。

  2. 关键质量需求和约束形成 ASR。

  3. ASR 写成可度量的 quality attribute scenarios 并排序。

  4. 架构师选择 tactics / patterns / design decisions 形成架构。

  5. 用视图文档化并评估；复杂业务进入 DDD，企业级转型进入 企业架构。

题块 先背关键词 对应页
基础概念 结构、关系、属性、决策、视图、取舍 02
质量与设计 六要素、ASR、tactic、ADD、七类决策 03
模式与微服务 上下文、问题、结构、收益、代价 04
DDD 与企业架构 边界、聚合、事件、4A、治理 05

# 名词中英文对照

英文术语 中文表达 答题提示
**Software **Architecture 软件架构 / 软件体系结构 结构、元素、关系、外部可见属性与关键决策
Quality Attribute 质量属性 性能、可用性、安全性、可修改性等可被场景和度量验证的属性
Architecturally Significant Requirement (ASR) 架构重要需求 / 架构攸关需求 会显著改变架构选择的需求
Quality Attribute Scenario 质量属性场景 Source、Stimulus、Artifact、Environment、Response、Measure
Tactic 战术 / 策略动作 直接控制质量响应的原子动作
Architectural Pattern 架构模式 上下文、问题、结构、收益与限制
Attribute-Driven Design (ADD) 属性驱动设计 本次复习说明以 ADD 3.0 七步为主
Microservice Architecture 微服务架构 围绕业务能力、独立部署，同时说明分布式代价
Bounded Context 限界上下文 统一语言适用且模型一致的业务边界
Aggregate / Aggregate Root 聚合 / 聚合根 一致性边界及唯一外部修改入口
Domain Event 领域事件 已发生的业务事实，用于解耦协作
Enterprise Architecture 企业架构 业务、数据、应用、技术四类架构与治理

# 英文题面速查扩展

**使用方法：**题目为英文时，先识别关键词，再用中文或英文完整作答；不要在同一题答案中中英文混用。下表英文来自课程纪要、语雀双语标题和 EagleBear 课程笔记标题，按考试范围筛选。

English term / phrase 中文 考试识别提示
Architecture vs. Design 架构与设计 架构是高层、早期、影响深远的设计决定；设计还包括更细粒度实现决定。
Architecture vs. Structure 架构与结构 Structure 偏元素及静态关系；Architecture 还关注运行时交互、质量属性、约束和演进。
Architecturally Significant Requirements (ASRs) 架构攸关需求 能显著影响架构设计的功能、质量属性、约束或设计目标。
Quality Attribute Workshop (QAW) 质量属性工坊 用于从利益相关者处补全质量属性场景和优先级。
Utility Tree 效用树 Utility → Quality Attribute → Sub-factor → Scenario，并按重要性/风险排序。
Generate and Test 生成与测试 生成候选架构，再用 ASR/质量属性场景验证和迭代。
Architecture Documentation 架构文档化 记录视图、接口、设计理由、约束、风险和评估依据。
Design Decisions 设计决策 责任分配、配置模型、数据、资源、映射、绑定时间、技术选择。
Layered Pattern / Multi-Tier Pattern 分层模式 / 多层部署模式 前者偏逻辑职责分层，后者偏物理部署分层。
Broker / MVC / Pipe-and-Filter / Client-Server / Peer-to-Peer 常见 C&C 模式 看到 pattern 题，按 Context → Problem → Structure → Benefit → Limitation 作答。
Service-Oriented Architecture (SOA) 面向服务架构 消费者、服务总线/治理、服务提供者；常与微服务比较。
Microservice Architecture 微服务架构 重点不背定义，把握业务能力拆分、独立部署、分布式代价和治理模式。
Strategic Design / Tactical Design 战略设计 / 战术设计 战略设计划边界和上下文；战术设计处理实体、值对象、聚合、事件等模型元素。
Bounded Context / Context Mapping 限界上下文 / 上下文映射 统一语言适用边界，以及上下文之间如何协作。
Aggregate / Aggregate Root / Repository / Domain Event 聚合 / 聚合根 / 仓储 / 领域事件 DDD 设计分析题中用于说明一致性边界、持久化隔离和业务事实解耦。
Enterprise Architecture / TOGAF / ADM / CBM 企业架构 / 主流方法 围绕业务、数据、应用、技术架构，以及方法论和实施路径作答。

# 简答必背 1：什么是软件架构，为什么重要

可直接作答：软件架构是系统的一组重要结构，包含软件元素、元素之间的关系以及元素的外部可见属性；它也是系统早期、关键且难以修改的一组高层设计决策。

为什么重要：

  1. 它是利益相关者沟通系统整体方案的媒介。

  2. 它促进或限制性能、可用性、安全性、可修改性等质量属性。

  3. 早期架构错误会随实现推进显著放大修改成本。

  4. 成熟架构能够作为可复用抽象迁移到同类系统中。

# 追问：Architecture、Structure、Design 的关系

背诵稿：

  • **Structure：**强调元素及其静态关系。

  • **Architecture：**在结构基础上进一步关注关键属性、运行时交互、约束和演进。

  • **Design：**从高层到细节的设计活动总称，架构设计属于其中最早、最抽象、影响最深的一部分。

**结论：**不是所有设计决定都是架构决定，但架构决定一定属于设计。

# 追问：架构师做什么

先记四类工作：Liaison / 联络人、软件工程最佳实践、技术知识、风险管理。

再背五项职责：

  1. **识别驱动因素：**识别 ASR / Architecturally Significant Requirements、约束、质量属性和涉众关注点。

  2. **设计或选择架构：**选择合适的架构风格、模式、战术和技术，并分配职责。

  3. **文档化与沟通架构：**用视图、接口说明、决策记录等表达架构，让团队能理解和实现。

  4. **评估风险并指导落地：**检查方案是否满足质量属性，识别风险、敏感点和权衡点，并指导实现、测试、部署和演进。

  5. **与利益相关者协商与权衡：**在业务目标、成本、进度、技术风险和质量属性之间做取舍。

**一句话：**架构师负责把驱动因素变成架构方案，再把方案讲清楚、评估风险、推动落地，并持续协调取舍。

# 简答必背 2：4+1 视图

**可直接作答：**复杂系统不能用一张图完整表达，因此需要从不同关注点形成视图。

  • **Logical View：**说明系统主要职责、对象结构和功能分解。

  • **Process View：**说明运行时并发、通信和交互。

  • **Physical View：**说明软件元素如何映射到硬件或部署节点。

  • **Development View：**说明代码模块、包结构和开发组织。

  • **+1 Use Case / Scenario：**用场景驱动并验证其他视图是否共同满足需求。

**记忆口诀：**逻辑回答“做什么”，过程回答“怎么跑”，物理回答“跑在哪”，开发回答“怎么造”，用例回答“是否真能满足需求”。

02 核心概念与架构过程

# 简答必背 3：需求、质量属性、约束与 ASR

可直接作答：

  • **Requirement: **包含功能需求、质量需求和约束，说明系统要做什么、做到什么程度、受到什么限制。

  • **Functional requirement：**系统要提供什么能力，例如登录或报价。

  • **Quality requirement：**能力要达到怎样的质量，例如响应时间、可用性或可修改性。

  • **Constraint：**设计中没有自由度的边界，例如必须使用既有平台或满足法规。

  • ASR：对架构有显著影响的需求，通常来自关键质量需求和重要约束；应写成可度量的质量属性场景，并结合业务目标与 涉众 讨论排序。

# 质量属性场景六要素

要素 背诵表达
Source 谁产生刺激
Stimulus 发生了什么事件
Artifact 被影响的系统或部分
Environment 事件发生时的运行条件
Response 系统应采取的响应
Response Measure 用于验证响应是否合格的量化标准

**例子：**在峰值负载环境下，高峰用户向报价服务发起查询请求，系统通过缓存或计算返回价格，且 95% 请求在 200ms 内完成。最后这句度量是场景可用于设计和验证的关键。

# 简答必背 4：Tactic、Pattern 、Style与七类设计决策

可直接作答：

Tactic 是为控制某个质量属性响应而采用的原子设计动作，例如为可用性引入冗余和故障检测，为可修改性提高内聚并限制依赖。

Pattern 是针对反复出现的问题，将多个设计决定和 tactics 组合起来的可复用方案，例如分层、Broker、Pipe-and-Filter 、SOA。

**Style **是不绑定具体问题的组织方式和约束集合。

进行完整架构设计时，还需覆盖七类设计决策：职责分配、协调模型、数据模型、资源管理、架构元素映射、绑定时机和技术选择。

**通用设计策略 **= 生抽可迭代二分

# 问答必背 5：ADD 的核心流程

**说明校正：**老师智能纪要明确复习 ADD 3.0 案例与七个步骤；扫描资料将软件架构设计列为章节，但 OCR 文本未给出另一版步骤。因此考试答题以 ADD 3.0 七步为主，题干另有版本时再按题干调整。

**可直接作答：**ADD 是属性驱动的迭代式架构设计方法。

  1. 确认需求和设计目标，选择本轮需要分解的系统元素。

  2. 识别最重要的 ASR。

  3. 针对设计关注点列出候选 patterns 和 tactics。

  4. 比较方案与 ASR 的关系，实例化架构元素并分配职责、接口和关系。

  5. 形成架构视图与决策记录，验证方案并进入下一轮迭代。

# 按老师纪要可写出的 ADD 3.0 七步

  1. 确定本轮设计目标。

  2. 选择驱动因素，包括关键功能、质量属性、设计目标与约束。

  3. 选择并细化待设计的系统元素。

  4. 针对驱动因素设计解决方案，比较 patterns、tactics 与取舍。

  5. 初始化架构元素并分配职责、接口和关系。

  6. 文档化设计，形成可沟通和可评估的视图及决策。

  7. 评审结果并进入下一轮迭代，直到重点驱动因素得到处理。

# ADD 2.0 与 ADD 3.0 的说明差异

**评论巡检补充：**ADD 2.0 可作为历史版本和对照说明掌握；本课程答题仍优先按老师纪要中的 ADD 3.0 七步展开。

版本 核心特点 答题用法
ADD 2.0 把质量属性与设计选择连接起来，组合使用 patterns 与 tactics；典型步骤包括选择待分解元素、识别架构驱动、选择设计概念、实例化元素、定义接口、验证并继续迭代。 若题目问版本演进，可答“从质量属性到模式/战术选择”；若只问 ADD 流程，不要用 ADD 2.0 替代本页 ADD 3.0 流程。
ADD 3.0 从 drivers 出发组织设计目的、关键需求与约束，强调 design concepts catalog、参考架构与快速迭代设计决策。 作为本库默认答题说明：设计目标 → 驱动因素 → 待细化元素 → 设计概念 → 架构元素/职责/接口 → 文档化 → 评审迭代。

事实源：slides/Designing Software Architectures - ADD 3.0.pdf 的 “A Brief History of ADD” 对比页，以及 slides/Reading Materials/SEI06_Attribute-driven_design_ver2_005_001_14795.pdf 中 ADD 2.0 步骤图。

# 问答必背 6：架构模式演进与微服务

可直接作答：架构模式演进本质上是在新的成本条件下重新组织协作方式。

  1. **主机终端：**集中计算，便于共享昂贵资源，但交互体验有限。

  2. **Client / Server：**利用客户端算力改善体验，但胖客户端维护困难。

  3. **Layered / SOA：**通过职责分层和服务复用改善维护性，但引入中间件开销和发布限制。

  4. **Microservices：**围绕业务能力拆分并独立部署，但带来网络故障、数据一致性和运维复杂性。

  5. **Cloud-native / Event-driven：**增强弹性和解耦，同时提高时序分析和排错难度。

# 微服务模式四类速记

按四类背：拆分、通信、部署、可观测性。题目问“微服务部署问题、相关上下文及可用模式”时，也可以沿这四类组织答案。

拆分 / Decomposition

  • **Decompose by Business Capability：**按业务能力拆服务。

  • **Decompose by Subdomain：**按 DDD 子域拆服务。

  • **Strangler Fig：**逐步替换旧单体。

  • **Database per Service：**明确服务数据归属。

通信 / Communication

  • **API Gateway：**统一外部入口。

  • **Service Discovery：**发现动态服务实例。

  • **Messaging / Event-driven：**异步解耦。

  • **Circuit Breaker / Saga：**故障隔离与跨服务一致性。

部署 / Deployment

  • **Service Instance per Host：**隔离强，资源利用可能低。

  • **Multiple Service Instances per Host：**资源利用高，隔离较弱。

  • **Service Instance per Container：**常见容器化部署方式。

  • **Serverless / FaaS：**按事件触发，适合短任务。

可观测性 / Observability

  • **Log Aggregation：**集中看日志。

  • **Distributed Tracing：**追踪跨服务调用链。

  • **Health Check API：**识别不健康实例。

  • **Metrics / Monitoring：**监控性能、容量和告警。

# 微服务和 SOA 的比较答案

**背诵稿：**SOA 与微服务都使用服务契约和分布式协作解决大型系统集成问题。

  • **SOA：**更强调企业级集成与复用，常借助 ESB、注册表和编排。

  • **Microservices：**更强调围绕业务能力的小粒度服务、轻量通信、独立部署和持续交付，常配合 API 网关、服务发现、断路器、容器化与可观测性。

  • **权衡：**微服务提高演进速度和扩展灵活性，但加重分布式故障、一致性与运维复杂性。

# 设计必背 7：DDD 设计分析题

**可直接作答：**DDD 适合业务规则复杂且变化耦合明显的系统。

  • **战略设计：**从问题空间出发，划分子领域，识别核心域、限界上下文、统一语言与上下文映射。

  • **战术设计：**在某个上下文内定义实体、值对象、聚合、聚合根、领域事件、Repository 和 Factory。

  • **聚合价值：**用聚合根建立一致性边界，外部修改只能通过根进行，从而减少跨对象依赖，让业务规则集中表达。

# 设计题五步回答法

  1. 指出原代码问题：贫血模型、业务逻辑散落、越过聚合边界、强耦合或一致性不清。

  2. 识别统一语言、领域事件和业务规则。

  3. 划分限界上下文、聚合与聚合根。

  4. 用应用服务编排用例、领域对象承载规则、Repository 隔离持久化、事件解耦外部动作。

  5. 回扣收益：一致性清楚、修改范围可控、领域模型与业务认知一致。

# 简答必背 8：企业架构

**可直接作答：**企业架构描述组织为实现共同目标而形成的核心组成部分、关系以及指导其设计和演进的原则。

  • **作用：**把战略目标分解为可执行的业务能力、数据、应用和技术建设，并通过标准化和治理控制复杂度。

  • **4A：**业务架构解释企业做什么，数据架构解释核心业务对象如何组织，应用架构解释应用如何支撑能力，技术架构解释基础设施如何承载应用。

  • **方法：**TOGAF 强调架构开发过程与治理，CBM 强调以业务组件组织能力。

# 考场答题模板

题型 落笔结构
概念简答 定义 → 组成/特征 → 作用 → 一句例子或对比
模式问答 Context → Problem → Elements/relations/constraints → Benefits → Limitations
论述题 现象对应矛盾 → 关键质量属性 → 结构选择 → 权衡与风险 → 结论
设计分析题 识别问题 → 提取 ASR/领域规则 → 给设计 → 解释职责与接口 → 验证收益

# 最后一分钟默写清单

  • [ ] 软件架构定义、四个重要性理由、架构师四类职责

  • [ ] 4+1 五个条目及各自回答的问题

  • [ ] 质量属性场景六要素与一个可度量例子

  • [ ] ASR、Utility Tree、tactic、pattern、七类设计决策

  • [ ] ADD 3.0 流程与老师纪要中的七个步骤

  • [ ] SOA 与微服务比较、三种微服务支撑模式

  • [ ] DDD 战略/战术、聚合根、事件风暴、设计题五步

  • [ ] 企业架构 4A、TOGAF 与 CBM

# 本页依据

  • 上传资料：《扫描文档20260526_192514.pdf》（MinerU OCR）的期末考试页、课程目录与架构模式演进页面。

  • 范围与优先级：三份飞书智能纪要，尤其是完整考前复习纪要中关于题型、重点和 AI 内容边界的说明。

  • 内容补足：`slides/` 下的原始课件，包括 `01_Introduction.pdf`、`02-04_Quality Attributes.pdf`、`06-07Attribute-Driven Design.pdf`、`08Microservices Architecture.pdf`、`09Architectural Decisions.pdf`、`10Enterprise Architecture.pdf` 与 `11-12Domain-Driven Design - Event Storming.pdf`。

  • 筛选规则：不以 `slides/readable_notes/` 二次转写文件作为知识库来源；需要补充时直接读取或 OCR 原始 slide PDF。

新增来源如何进入 00：

  • **语雀整合资料：**只吸收与考试范围一致的题型提示、术语整理和画图训练入口。

  • **EagleBear 英文笔记：**用于补充英文题面和术语表达，不替代老师课件定义。

  • **三份飞书纪要：**用于校正考试边界，尤其是 AI 增强 / AI 原生不纳入期末考试要求。

(注：内容由 AI 生成，请谨慎参考）