软件架构设计

历年题与训练答案

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

# 06 历年题与训练答案

# 历年题高频训练清单

本页读法：06 是刷题页，不建议从头硬读。先用下面的三步路线定位题型，再按 2025 → 2024 → 2023 → 2015-2019 的时间倒序刷题；遇到画图题先看图，再背文字。

**答题表述：**本页是刷题页，遇到知识点时请和前面专题页保持一致：质量属性场景写六要素，ASR 写成显著影响架构的需求或约束，ADD 3.0 按“驱动因素 → 待分解元素 → 设计概念 → 实例化 → 文档化 → 评审迭代”表达，DDD 按 05 页六步组织，TOGAF / ADM / CBM 分别理解为企业架构框架、架构开发方法 / 流程、业务组件 / 业务能力建模方法。

# 1. 先抓高频题型

  • 质量属性 / ASR / ADD

  • 4+1 与 UML 画图

  • 架构模式与微服务

  • DDD 与企业架构

# 2. 再按年份刷题

  • **2025：**Architecture / Structure / Design、4+1、C&C / P2P、可用性公式、Pipe-and-Filter、DDD、企业架构、微服务与 SOA。

  • **2024：**刺激-响应图、Layered vs Multi-tier、ADD、七类决策、微服务容器、DDD、企业架构、迁移设计。

  • **2023：**概念、4+1、Broker、SOA、DDD、企业架构、微服务部署、Call Graph 画图。

# 3. 最后补训练

  • **知乎补充：**只作练题线索，不替代本课程资料。

  • **作业题：**用于扩展设计题表达。

  • **自测：**临考前只看关键词和图。

# 复习索引：题型、来源、英文题面与画图入口

**读法：**先按题型定位要背的知识点，再按年份刷具体题；遇到英文题面时优先识别动词（define / compare / describe / draw / design），最后回到对应题目下看答案、画图和知识出处。

# 按题型快速定位

  • **概念定义题：**软件架构、ASR、质量属性、C&C、DDD、企业架构、TOGAF / ADM / CBM。

  • **过程方法题：**ADD、ATAM、DDD 一般过程、企业架构建设过程、架构文档化。

  • **画图题：**4+1 视图、质量属性刺激-响应图、C&C 运行视图、微服务部署图、在线课程平台迁移图。

  • **模式比较题：**Layered / Multi-tier、SOA / Microservices、Pipe-and-Filter、Broker、P2P。

  • **设计分析题：**DDD 代码评价/重构、微服务部署决策、企业架构与数字化转型、设计决策关系。

# 按来源使用

  • **2023 / 2024 本课程回忆版：**作为主线真题训练，题目和参考回答已经逐题整理。

  • **2025-06-04 真题回忆版：**来自本地 2025软件系统设计回忆.pdf，按用户确认作为 2025 真题回忆版整理，答案用于复习表达训练，不是官方标准答案。

  • **2015B-2024 外部线索与研究生版资料：**用于补全高频考点、题型表达和易混点，已去重后并入逐题清单。

# 英文题面速查

  • **Define / explain：**先给定义，再说明作用、边界和例子。

  • **Compare：**先定性两者分别是什么，再从关注点、结构、优缺点和适用场景比较。

  • **Describe process：**按输入、步骤、输出和迭代/治理机制组织答案。

  • **Draw / model / design：**先说明设计目标和质量属性，再给图，最后解释关键元素、连接器和取舍。

# 画图入口

  • **2023-12｜Call Graph 架构设计画图题：**题目下方已合并 C&C 运行视图画图示例。

  • **2024-03｜互操作性与性能刺激-响应图：**练质量属性场景与刺激-响应链路。

  • **2024-05｜4+1 视图与 UML：**练逻辑视图、开发视图、进程视图、物理视图与场景视图的具体画法。

  • **2024-12｜在线课程平台迁移设计题：**练微服务拆分、部署模式和渐进迁移方案。

**卡片阅读规则：**题目与回答尽量相邻；有画图需求的题，图直接放在对应题目附近，避免先看索引再跳到页面末尾。

# 研究生版整理：去重版逐题清单

**来源说明：**本节来自本地 研究生版/ 文件夹、研究生往年题版.md、2023/2024 回忆版、2015-2019 往年题整理、复习梳理 PDF、微服务-DDD-企业架构 PDF，以及前面专题页。它的用途是把重复题压缩成可背、可画、可迁移的训练清单；具体年份题仍保留在后文。

**去重规则：**同一知识点跨年份反复出现时，只保留一个归并题；答案统一使用前面专题页的表述，避免同一概念在 06 页出现多种说法。独有的设计分析题单独保留，并补上画图入口。

# 去重后的高频题

# 1. 软件架构：定义、来源、重要性与架构师职责

**出现来源：**2024-01；2023-01；2015/2019 “Where do software architecture come from”；复习梳理 PDF；研究生往年题版.md:1-31。

**题目：中文：**说明 软件架构 是什么、来自哪里、为什么重要，并写出 软件架构师职责。 **English prompt：**What does a software architect do? Where do software architectures come from? List five possible sources of software architecture.

参考回答：软件架构 是系统的一个或多个 结构，包括 软件元素、元素的 外部可见属性 以及元素之间的 关系。架构不是凭空产生的，通常来自 业务目标、功能需求、质量属性、约束、涉众关注点、组织经验、架构师经验、技术环境和既有系统。

  • **为什么重要：**架构承载早期关键决策，越到后期修改代价越大；它直接促进或阻碍性能、可用性、可修改性、安全性等质量属性；它也是涉众沟通、开发分工、风险管理和复用迁移的共同抽象。

  • 五项职责：

    • 创建或选择架构；文档化并沟通架构；分析、评估和解释架构风险；指导实现与技术选型；保证实现与架构决策保持一致。

    • 也可能是这个版本：00 直接背诵总纲与答题模板

  • **角色能力：**可补充 Liaison（联络涉众）、Software Engineering（软件工程实践）、Technology Knowledge（技术知识）、Risk Management（风险管理）。

# 2. 需求、质量属性与 ASR

**出现来源：**2023-02；2015/2016/2018 需求关系题；2017/2019 ASR 来源题；复习梳理 PDF。

**题目：中文：**说明 software requirements、quality attributes 和 ASR 的区别与联系；列出识别 ASR 的来源和方法。 **English prompt：**Describe the difference and relationship between software requirements, quality attributes, and architecturally significant requirements. What are ASRs? List sources and methods for extracting and identifying ASRs.

参考回答：需求 描述系统要满足什么，通常包括 功能需求、质量需求 和 约束。质量属性 描述系统要做到多好，如性能、可用性、可修改性、安全性。ASR（Architecturally Significant Requirement，架构攸关需求） 是显著影响架构结构、模式、职责分配、部署或技术选择的需求或约束。

  • **关系：**质量属性经常成为 ASR，但不是所有质量属性都显著影响架构；功能需求和约束只要驱动架构决策，也可以成为 ASR。

  • **来源：**需求文档、业务目标、stakeholder 访谈、utility tree / workshop、已有系统、法规约束、技术平台和运行环境。

  • **识别方法：**看它是否会驱动架构模式、职责分配、数据模型、资源管理、部署映射、绑定时间或技术选择；会驱动这些决策的，就优先作为 ASR。

# 3. 质量属性刺激-响应建模

**出现来源：**2024-03；2023-03；2015 availability/performance；2017 availability/modifiability；2018 availability/modifiability；2019 interoperability/modifiability；README 质量属性图。

**题目：中文：**用 刺激-响应图 建模 可用性、性能、互操作性、可修改性 等质量属性。 **English prompt：**How to model quality attribute scenarios? Graphically model availability, performance, interoperability, or modifiability in stimulus-response format.

**参考回答：**统一写 质量属性场景六要素：刺激源、刺激、环境、制品、响应、响应度量。最后一个必须可测试，不能只写“很快”“稳定”。

  • **性能：**高峰期用户发起查询，系统在正常运行环境下处理，95% 请求在 200ms 内返回。

  • **可用性：**服务节点故障，系统在降级环境中切换到备用实例，30 秒内恢复核心功能。

  • **互操作性：**外部支付系统发送合规请求，系统完成协议/数据转换并返回双方可解析结果。

  • **可修改性：**开发者提出变更请求，在正常开发环境中修改限定模块，2 人日内完成并通过回归测试。

# 4. 通用设计策略、Tactics / Patterns 与七类设计决策

**出现来源：**2024-02、2024-07；2015 tactics/patterns；2017/2019 generic design strategies；slides/01_Introduction.pdf 第 24 页；03 质量属性、ASR 与 ADD。

**题目：中文：**说明 generic design strategies；解释 tactics 与 patterns 的关系；写出 七类设计决策。 **English prompt：**What are generic design strategies applied in designing software? Give a concise working example for each strategy. Describe relationships between architecture patterns and tactics. List four tactics and describe their usage.

参考回答：通用设计策略（Generic Design Strategies） 是做架构设计时反复使用的思维工具，可按 slides 写六项：Abstraction / 抽象、Decomposition / 分解、Divide and Conquer / 分而治之、Generate and Test / 生成与测试、Iteration or Incremental Refinement / 迭代式增量细化、Reusable Elements or Reuse / 复用元素。

  • **策略例子：**用支付接口做 Abstraction；按课程、订单、支付做 Decomposition；把迁移拆成网关接入、服务抽取、数据迁移做 Divide and Conquer；生成候选架构并用 ASR 场景评估做 Generate and Test；在 ADD 中逐轮细化做 Iteration；复用 API Gateway、消息队列、容器平台和成熟模式做 Reuse。

  • Tactic 与 Pattern：tactic 是面向某个质量属性的小粒度设计手段，如缓存、冗余、心跳、限流、身份认证、异步消息、超时与重试；pattern 通常把多个 tactics 与结构决策组合成可复用方案，如 Broker、Layered、Pipe-and-Filter、Microservices。

  • 七类设计决策：Allocation of Responsibilities / 职责分配、Coordination Model / 协调模型、Data Model / 数据模型、Management of Resources / 资源管理、Mapping among Architectural Elements / 架构元素映射、Binding Time Decisions / 绑定时间、Choice of Technology / 技术选择。

# 5. 架构过程、ADD 与架构评估概念

**出现来源：**2024-06；2023-05；2015/2016/2017 架构过程输入输出；2015/2016/2018 ADD；复习梳理 PDF；研究生往年题版.md:8-10。

**题目：中文：**描述 软件架构过程 及每个阶段的输入输出；描述 ADD 过程；说明 risk、sensitivity point、trade-off point。 **English prompt：**Briefly describe the general activities involved in a software architecture process and the major inputs and outputs at each activity. Briefly describe the Attribute-Driven Design (ADD) process. What are risks, sensitivity points, and trade-off points?

**参考回答：**架构过程可按“识别 ASR → 架构设计 → 架构文档化 → 架构评估”组织。ADD（Attribute-Driven Design） 是以质量属性和 ASR 驱动的迭代设计方法；考试中可写为：确认设计目标与输入 → 选择待分解元素 → 识别驱动因素 → 选择设计概念 → 实例化元素、职责、接口和关系 → 文档化设计 → 评审并进入下一轮。

  • **识别 ASR：**输入业务目标、需求、约束、涉众关注点；输出优先级质量属性场景和关键约束。

  • **架构设计：**输入 ASR、需求、约束、候选 tactics / patterns；输出候选视图、职责分配、接口和设计决策。

  • **文档化与评估：**输入架构草图、设计理由、质量场景；输出视图文档、风险、敏感点、权衡点和下一轮修改建议。

  • 评估术语：risk 是可能导致质量目标失败的架构问题；sensitivity point 是对某一质量属性敏感的设计点；trade-off point 同时影响多个质量属性，例如缓存提升性能但可能降低一致性。

# 6. 多视图、4+1 与 Views and Beyond

**出现来源：**2024-05；2023-06；2017/2018/2019 多视图题；2015/2019 style/view 连线题；2016 ATM 题；02 核心概念与架构过程。

**题目：中文：**为什么架构需要 不同视图？说明 4+1 视图，并能用 Views and Beyond 表达设计。 **English prompt：**Why should a software architecture be documented using different views? Give the names and purposes of four example views. Describe the 4+1 view model. Document your design using the Views and Beyond approach.

**参考回答：**不同涉众关注不同问题，多视图 分别表达静态结构、运行时交互、部署映射和代码组织，并帮助发现视图间不一致。

  • **Logical View / 逻辑视图：**关键领域对象和职责，可用类图。

  • **Development View / 开发视图：**模块、包、组件和代码组织，可用组件图或包图。

  • **Process View / 进程视图：**运行时进程、线程、交互、并发、同步和性能关注点，可用时序图或通信图。

  • **Physical View / 物理视图：**软件元素到硬件或部署节点的映射，可用部署图。

  • **Scenarios / +1 场景：**用例图或关键质量场景，用来贯通并验证四个视图。

# 7. Layered、Multi-tier、C&C、MVC、Broker、SOA 与微服务

**出现来源：**2024-04、2024-11；2023-07、2023-08；2015/2016 Layered、Broker、SOA、C&C/MVC；2019 SOA/微服务；README 架构模式图；04 架构模式演进与微服务。

**题目：中文：**比较 Layered Pattern 和 Multi-tier Pattern；说明 C&C 本质并以 MVC / Broker / SOA 举例；比较 分层、SOA 和 微服务。 **English prompt：**Compare Layered Pattern and Multi-tier Pattern. What is the nature of component-connector style? Describe MVC as an example. Explain the context, benefits and limitations of Broker Architecture Pattern. Briefly describe SOA principles and compare SOA with microservices.

参考回答：Layered 是逻辑职责分层，属于模块组织；Multi-tier 是部署分层，关注运行节点、网络边界和伸缩。C&C（Component-and-Connector） 描述运行时组件与连接器，重点回答组件如何通信、同步、传递数据和协作。

  • **MVC：**Model、View、Controller 通过运行时连接器协作，Controller 协调用户动作、模型变化和视图更新；它更适合作为 C&C 风格例子讲运行协作。

  • **Broker：**适合分布式客户端/服务端通过中介定位和通信；优点是解耦、位置透明、可扩展；局限是复杂度、性能瓶颈、单点风险、安全风险和测试困难。

  • **SOA：**强调企业级服务契约、服务复用和治理，常见元素有服务提供者、服务消费者、服务注册表、ESB（Enterprise Service Bus，企业服务总线）、编排服务器。

  • **微服务：**强调小自治服务、围绕业务能力拆分、独立部署、去中心化治理和基础设施自动化，常用 API Gateway、服务发现、熔断、链路追踪和容器平台支撑。

# 8. DDD：过程、战略/战术设计、聚合与核心概念

**出现来源：**2024-09；2023-04、2023-09；复习梳理 PDF；微服务-DDD-企业架构 PDF；05 DDD、事件风暴与企业架构。

**题目：中文：**说明 DDD 一般过程；区分 战略设计 和 战术设计；分析 聚合模式 价值；解释 实体、值对象、领域服务、领域事件、限界上下文。 **English prompt：**Describe the general process of Domain-Driven Design (DDD). What is the difference between strategic design and tactical design in DDD? Give examples. Compare with object-oriented design and analyze the value of introducing the Aggregate pattern.

参考回答：DDD 答题按 05 页六步组织：适用性与痛点 → 统一语言与领域事件 → 限界上下文与上下文映射 → 战术建模 → 协作落地 → 收益与代价。其中 事件风暴（Event Storming） 是从业务事件出发识别命令、参与者、聚合、读模型和上下文边界的协作建模方法，适合放在“统一语言与领域事件”之后。

  • **战略设计：**解决边界和方向问题，关注子域、核心域、限界上下文、上下文映射和统一语言；例子是把在线课程系统拆成课程、选课、订单、支付上下文。

  • **战术设计：**解决模型内部怎么落到代码，关注实体、值对象、聚合、聚合根、领域服务、领域事件和资源库；例子是设计 Order 聚合根和 OrderPaid 领域事件。

  • **聚合价值：**聚合根封装一致性边界，保护业务不变量，减少跨对象依赖，避免业务逻辑散落成 贫血模型（Anemic Domain Model）。

  • **概念速记：**实体看身份连续性；值对象看值相等和不可变性；领域服务放不适合归属到单个实体/值对象的领域行为；领域事件表达已发生的业务事实；限界上下文划定模型语义边界。

# 9. 微服务部署、容器模式与迁移设计

**出现来源：**2024-08、2024-12；2023-11；微服务-DDD-企业架构 PDF；研究生往年题版。

**题目：中文：**说明 微服务特性、部署问题、容器模式，并设计从 分层架构 迁移到 微服务 的方案。 **English prompt：**Describe the microservice deployment problem, related context, and available patterns. Explain the Service Instance per Container pattern: context, requirements, benefits and limitations. Design a migration plan from a layered architecture to a microservice architecture.

参考回答：微服务 强调服务组件化、围绕业务能力组织、高内聚低耦合、去中心化、独立部署、基础设施自动化和演进式设计。部署问题集中在服务实例隔离、资源利用、配置、发布、监控、回滚、故障定位和数据一致性。

  • **部署模式：**single-host multiple services、multiple hosts、service instance per VM、service instance per container、serverless / platform-based deployment。

  • **容器模式：**适合大量服务独立部署、快速启动、环境一致和弹性伸缩；限制是编排、服务发现、网络治理、日志监控、镜像安全和状态数据管理复杂。

  • **迁移方案：**识别业务能力 → 划分服务边界 → 建 API Gateway 和服务发现 → 按 Strangler 思路逐步抽出服务 → 处理数据库拆分和数据同步 → 容器化部署 → 灰度发布 → 监控回滚。

# 10. 企业架构：基本作用、一般过程与经典方法

**出现来源：**2024-10；2023-10；复习梳理 PDF；微服务-DDD-企业架构 PDF；05 DDD、事件风暴与企业架构；企业架构.md。

**题目：中文：**说明 企业架构 的 basic function、一般设计过程和经典方法。 **English prompt：**What are the basic functions of Enterprise Architecture? Briefly describe the general design process of enterprise architecture and classic methods.

参考回答：企业架构（Enterprise Architecture, EA） 用全局、结构化方式连接企业战略、业务能力、应用系统、数据、技术平台和治理落地，核心作用是管理复杂性、分解战略目标、统一标准、指导投资与演进路线图。

  • **一般过程：**从战略与业务目标出发，梳理业务架构、数据架构、应用架构、技术架构，再补充安全/治理、迁移路线图和实施治理。

  • TOGAF：The Open Group Architecture Framework，是企业架构框架，回答企业架构工作怎么组织、治理和持续演进。

  • ADM：Architecture Development Method，是 TOGAF 中用于推进架构开发的核心方法流程，不是和 TOGAF 并列的另一个框架。

  • CBM：Component Business Model / Business Component Modeling，是从业务能力出发拆分业务组件的建模方法，偏业务建模和能力拆解，不是完整企业架构治理框架。

# 11. 软件产品线与可变性

**出现来源：**2016 software product line；2018 产品线可变性；质量属性 slides 中 product line engineering 相关内容。

题目：中文：软件产品线架构 与 单产品架构 有什么不同？如何实现 可变性？ **English prompt：**What distinguishes an architecture for a software product line from an architecture for a single product? How does a software product line architecture realize variability?

参考回答：软件产品线架构（Software Product Line Architecture） 面向一组共享核心资产、面向同一市场或业务族的产品，不是只为一个系统做一次性设计。它既要表达 共性，也要显式表达 变异点、绑定时间 和 产品派生规则。

  • **和单产品架构的区别：**单产品架构关注一个系统当前需求；产品线架构关注多产品复用、演进和可配置性，因此需要核心资产库、特性模型、变异点说明和 variability guide。

  • **可变性机制：**配置、插件、特性开关、抽象接口、继承/组合、策略模式、构建时绑定、部署时绑定、运行时绑定。

  • **答题提醒：**可变性不是“什么都能改”，而是在受控边界内让产品差异可配置、可测试、可追踪；绑定时间越晚越灵活，通常成本和运行复杂度也越高。

# 12. 基础辨析题：科学/工程、软件/硬件、架构/设计/结构、抽象

**出现来源：**复习梳理 PDF；2015/2016/2019 architecture/design/structure；前面核心概念页。

**题目：中文：**区分 Science 和 Engineering、Software 和 Hardware、Architecture 和 Design、Architecture 和 Structure；说明为什么架构需要 抽象。 **English prompt：**What is the difference between Science and Engineering? What is the difference between Software and Hardware? What is the difference between Architecture and Design? What is the difference between Architecture and Structure? Why is abstraction needed in architecture?

  • **Science / Engineering：**科学研究既有世界和规律；工程在约束下创造满足目标的人造系统。

  • **Software / Hardware：**软件是逻辑制品，复制成本低、演化频繁、复杂度来自状态和依赖；硬件是物理制品，生产、修改和失效方式不同。

  • **Architecture / Design：**架构是设计的一部分，关注高层结构、关键决策、质量属性和演化约束；详细设计关注类、接口、算法、表结构等局部实现。

  • **Architecture / Structure：**结构是系统组成和关系的表达；架构还包含外部可见属性、运行时关系、约束、决策理由和质量属性影响。

  • **Abstraction / 抽象：**抽象隐藏实现细节，降低复杂度，让涉众围绕关键结构、质量属性和权衡讨论系统。

# 去重后保留的设计分析题

# 1. Call Graph 抽取程序架构设计

**出现来源：**2023-12；本页后文 2023-12 已保留具体题目。

**题目：中文：**为抽取程序 call graph 的程序选择架构 pattern，说明理由、高优先质量属性，用 module view 描述职责分配，并用 C&C 风格画 runtime elements。 **English prompt：**Design an architecture for a program that extracts a program call graph. Choose an architectural pattern and justify it, identify high-priority quality attributes, describe responsibility allocation using a module view, and draw the runtime elements in a C&C view.

**参考回答：**优先选 Pipe-and-Filter 或数据流型 C&C。理由是源码分析天然按“读取 → 解析 → 符号解析 → 调用关系分析 → 图构建 → 导出”流动，Filter 可替换，方便支持多语言和多种导出格式。

  • **ASR：**可修改性（新增语言前端）、性能（大项目分析）、可测试性（各阶段可单测）、可扩展性（新增图分析/导出插件）。

  • **Module View：**Source Input、Language Frontend / Parser、AST Model、Symbol Resolver、Call Analyzer、Graph Builder、Store、Exporter / Visualizer。

  • **C&C View：**Parser 把 AST 通过 Pipe 交给 Analyzer；Analyzer 调用 Symbol Resolver；Graph Builder 生成调用图；Store 保存；Exporter 输出 GraphML / JSON / 图片。

# 2. 在线课程平台从分层迁移到微服务

**出现来源：**2024-12；本页后文 2024-12 已保留具体题目。

**题目：中文：**在线课程平台原为 分层架构，迁移到 微服务。说明采用什么模式，比较 single-host、multi-host 和 container，设计迁移方案。 **English prompt：**An online course platform currently uses a layered architecture. Migrate it to a microservice architecture: choose implementation patterns, compare single-host, multi-host, and container deployment, and design the migration plan with milestones and deliverables.

**参考回答：**按 业务能力 拆分课程、用户、订单/支付、学习进度、通知等服务；用 API Gateway、Service Discovery、Container Deployment、配置中心和可观测性支撑迁移。推荐用容器作为实验方案，因为它最能体现独立部署、环境一致和弹性伸缩。

  • **部署比较：**single-host 简单但隔离和伸缩差；multi-host 改善隔离但部署运维复杂；container 在隔离、镜像交付、弹性和自动化上更适合微服务，但需要编排、日志、监控和网络治理。

  • **里程碑：**能力拆分 → 接口契约 → 选一个低风险服务试点抽取 → 数据迁移与同步 → 容器化部署 → 灰度发布 → 监控告警 → 回滚预案。

  • **验证：**用响应时间、发布频率、故障隔离时间、回滚时间、服务可用性和数据一致性检查迁移效果。

# 3. ATM 的 Three-tier 架构

**出现来源：**2016 ATM 设计题。

**题目：中文：**用 three-tier style 设计 ATM 应用，并用 Views and Beyond 说明职责。 **English prompt：**Design a simple architecture for an automated teller machine (ATM) application in the three-tier style. Explain what responsibilities each component has. Document your design using the Views and Beyond approach.

参考回答：Three-tier 是典型部署/分配思路，可分为 Presentation Tier / 表示层、Business Logic Tier / 业务层、Data Tier / 数据层。ATM 题要把职责和运行交互讲清楚，而不是只列三层名字。

  • **表示层：**ATM UI、读卡、密码输入、菜单、收据/屏幕输出，只做交互和输入校验。

  • **业务层：**认证、取款、查询、转账、限额、账户规则、交易事务和异常处理。

  • **数据层：**账户数据库、交易流水、审计日志和持久化事务。

  • **Views and Beyond：**模块视图讲三层职责；C&C 视图讲 ATM 终端请求业务服务；部署视图讲 ATM 终端、应用服务器、数据库服务器的节点映射。

# 4. 飞行模拟软件与策略模式

**出现来源：**2018 飞行模拟设计题。

**题目：中文：**设计 飞行模拟软件，支持多种飞机特性，要求使用 策略模式，画 架构图 和 类图。 **English prompt：**Design a flight simulation software that supports multiple aircraft characteristics. Use the Strategy Pattern, and draw the architecture diagram and class diagram.

**参考回答：**把会变化的飞行行为、发动机行为、控制行为或机型特性抽象成 Strategy 接口；Aircraft 组合不同 Strategy；Simulator 负责仿真循环、时间推进和可视化，不直接写死某种飞机算法。

  • **变化点：**不同飞机的飞行动力学、发动机推力、控制响应、传感器模型和故障处理。

  • **架构图：**Simulator 依赖 Aircraft Model、Strategy Library、Physics Engine、Visualization。

  • **类图：**Aircraft 组合 FlightStrategy / EngineStrategy / ControlStrategy；新增机型时新增策略实现或配置，不改 Simulator 主流程。

知识出处：02 核心概念与架构过程；03 质量属性、ASR 与 ADD；04 架构模式演进与微服务；05 DDD、事件风暴与企业架构。

# 2025-06-04 真题回忆版（好像是本科课程的题目）

**来源说明：**以下来自本地 2025软件系统设计回忆.pdf / 2025软件系统设计回忆.md，按用户确认作为 2025 真题回忆版 整理。答案用于复习表达训练，不是官方标准答案。涉及 AI 原生架构的题目按题面保留，但复习优先级仍以老师复习纪要、原始 slides 和前面专题页为准。

# 一、简答题

# 2025-01｜Architecture、Structure 和 Design

**题目：**说明 Architecture、Structure 和 Design 之间的区别。

参考回答：Architecture / 架构 是影响系统整体形态和质量属性的关键设计决策集合，关注软件元素、外部可见属性、关系以及这些结构背后的理由；Structure / 结构 是架构被表达出来的一种具体组织方式，例如模块结构、Component-and-Connector（C&C）运行结构、部署结构；Design / 设计 范围更大，既包括架构层面的高层设计，也包括类、接口、算法、数据库表等详细设计。

  • **一句话：**架构是最重要、最难回退、最影响质量属性的设计子集；结构是架构的表达方式；设计还包含更细的实现层决策。

  • 例子：“采用微服务”是架构决策；“服务、数据库、网关如何连接”是结构表达；“某个接口参数和类方法怎么写”是详细设计。

知识出处：02 核心概念与架构过程；题面来源：2025软件系统设计回忆.md:5。

# 2025-02｜4+1 视图

**题目：**描述 4+1 视图（Describe Philippe Kruchten’s “4+1” views）。

参考回答：4+1 视图用多个视角描述同一个系统：**逻辑视图（Logical View）**看领域对象与职责，常用类图；**开发视图（Development View）**看模块、包、组件与代码组织，常用组件图或包图；**进程视图（Process View）**看运行时进程、线程、交互、并发和同步，常用时序图或通信图；**物理视图（Physical View）**看节点、网络和部署，常用部署图；**场景 / 用例视图（Scenarios / Use Cases）**作为 “+1”，贯通并验证其他四个视图。

  • **答题顺序：**先说“不同视图服务不同涉众和关注点”，再列四视图，最后说明 +1 场景用于验证架构。

  • **画图策略：**同一业务场景贯通五张图，避免每张图讲不同系统。

知识出处：02 核心概念与架构过程；本页 2023-06 已给出 UML / PlantUML 画法。

# 2025-03｜C&C 与 P2P

**题目：**解释 组件连接器模式（Component-and-Connector, C&C），以 点对点（Peer-to-Peer, P2P） 模式为例说明。

参考回答：C&C 描述系统运行时的 组件（components） 和 连接器（connectors），重点回答组件如何通信、同步、传递数据、发现彼此并协作。P2P 是一种 C&C 风格：每个节点既可以作为客户端请求资源，也可以作为服务端提供资源，节点之间通过网络协议、消息或连接管理机制通信。

  • **优点：**去中心化、扩展性好、单个节点失效不一定导致全局失效，适合资源分布式共享。

  • **代价：**节点发现、路由、一致性、安全控制、调试和治理更复杂。

  • **答题别漏：**先解释 C&C 的“组件 + 连接器”，再把 P2P 映射到节点和网络协议。

知识出处：04 架构模式演进与微服务；题面来源：2025软件系统设计回忆.md。

# 2025-04｜可用性、MTBF、MTTR 与 SLA

**题目：**解释 可用性（Availability）。MTBF 和 MTTR 分别代表什么？可用性 / SLA 计算公式是什么？

参考回答：Availability / 可用性 表示系统在需要时能够正确提供服务的程度。MTBF（Mean Time Between Failures） 是平均故障间隔，越大越好；MTTR（Mean Time To Repair） 是平均修复时间，越小越好。常用公式为：Availability = MTBF / (MTBF + MTTR)。

  • **提分点：**不要只写公式，还要说明提升路径：冗余、故障检测、故障转移、降级、自动恢复、缩短修复时间。

  • 场景表达：“服务节点故障后，系统在 30 秒内切换到备用实例并恢复核心功能”就是可测试的可用性场景。

知识出处：03 质量属性、ASR 与 ADD；slides/02-04_Quality Attributes.pdf。

# 2025-05｜Pipe-and-Filter

**题目：**说明 Pipe-and-Filter 模式的上下文、优缺点和局限性。

参考回答：Pipe-and-Filter 适用于数据按步骤被转换、清洗、分析或生成的场景。Filter 是独立处理步骤，负责输入到输出的转换；Pipe 是连接器，负责把一个 Filter 的输出传给下一个 Filter。

  • **优点：**职责清晰、Filter 可复用/替换、易测试、易并行，适合编译器、日志处理、数据分析流水线。

  • **局限：**全局状态难处理，交互式流程不适合，错误处理、背压、数据格式转换和性能开销需要额外设计。

  • **例子：**Call Graph 抽取可写成 Source → Parser → Resolver → Graph Builder → Store / Exporter。

知识出处：04 架构模式演进与微服务；本页 2023-12 Call Graph 题。

# 2025-06｜架构文档内容

**题目：**架构文档中应该包含哪些重要内容？

**参考回答：**架构文档不是只画图，应覆盖 背景与目标、涉众关注点、ASR、架构视图、接口、关键设计决策、决策理由、质量属性场景、约束、风险、权衡和验证方式。写作时可按“视图 + 决策 + 理由 + 验证”组织。

  • **视图：**逻辑、开发、进程、物理、C&C、部署等，按题目需要选择。

  • **决策：**记录采用某模式、拆分某服务、选择某技术的原因和被拒绝方案。

  • **验证：**用质量属性场景、ATAM / review、原型或测试指标说明架构能支撑目标。

知识出处：02 核心概念与架构过程；03 质量属性、ASR 与 ADD。

# 2025-07｜AI 原生架构边界

题目：说明 AI 原生架构 的 scope，以及涉及的三个 pattern。

参考回答：本题按 2025 真题题面保留。可把 AI 原生架构 的范围写成：以模型能力为核心，把 模型、数据、工具调用、Agent 编排、反馈闭环、运行时治理和安全控制 纳入架构设计。三个常见 pattern 可写 RAG（Retrieval-Augmented Generation）、Agent / Tool-use、Model Gateway / Model Routing。

  • RAG：把检索系统和生成模型组合，降低幻觉并利用私有知识。

  • Agent / Tool-use：让模型通过工具完成多步任务，但要处理权限、可观测性和失败恢复。

  • Model Gateway / Routing：统一模型接入、路由、限流、审计和降级。

答题边界：这是 2025 回忆题中的新题型，不要把 AI 原生内容倒灌成前面专题页的主线结论；考试作答以题面要求为准。

# 2025-08｜DDD 战略设计与战术设计

**题目：**区分 DDD 中的 战略设计 和 战术设计，并各举两个例子。

参考回答：战略设计（Strategic Design） 解决业务边界和协作关系问题，关注 子域（Subdomain）、核心域（Core Domain）、限界上下文（Bounded Context）、上下文映射（Context Map）、统一语言（Ubiquitous Language）。战术设计（Tactical Design） 解决一个上下文内部模型怎么落到代码，关注 实体（Entity）、值对象（Value Object）、聚合 / 聚合根（Aggregate / Aggregate Root）、领域服务（Domain Service）、领域事件（Domain Event）、资源库（Repository）。

  • **战略例子：**把在线课程系统划分为课程、选课、订单、支付等限界上下文；用上下文映射说明支付上下文和订单上下文如何协作。

  • **战术例子：**在订单上下文内设计 Order 聚合根和 OrderPaid 领域事件；用 OrderRepository 保存聚合。

知识出处：05 DDD、事件风暴与企业架构；DDD.md；slides/11-12Domain-Driven Design - Event Storming.pdf。

# 2025-09｜企业架构与数字化转型

**题目：**说明 企业架构 的核心及其在企业数字化转型中的作用。

参考回答：企业架构（Enterprise Architecture, EA） 的核心是把企业战略和数字化实施连接起来，用 业务架构、数据架构、应用架构、技术架构 描述企业能力、系统、数据和技术之间的关系。它在数字化转型中的作用是识别能力缺口、统一建设蓝图、减少重复建设、指导投资优先级、治理标准，并让业务变化能够落到系统演进路线图上。

  • **TOGAF：**The Open Group Architecture Framework，是企业架构框架，回答企业架构工作怎么组织和治理。

  • **ADM：**Architecture Development Method，是 TOGAF 中推进架构开发的核心方法流程。

  • **CBM：**Component Business Model / Business Component Modeling，是从业务能力出发拆分业务组件的建模方法。

知识出处：05 DDD、事件风暴与企业架构；slides/10Enterprise_Architecture.pdf。

# 2025-10｜架构决策之间的关系

**题目：**说明架构决策之间的关系（Possible relations between design decisions）。

参考回答：架构决策（design decisions） 之间不是孤立列表，而是会形成一个可追踪的关系网络。按 slides/09Architectural Decisions.pdf 第 46 页，可写八类关系：constrains / 约束、excludes / 排除、enables / 启用、subsumes / 包含、conflicts with / 冲突、overrides / 覆盖、is an alternative to / 互为备选、is related to / 弱相关。

  • **约束 / 启用：**选择 Microservices 会约束数据拆分和部署方式，同时启用独立发布、服务发现、API Gateway、链路追踪等决策。

  • 排除 / 备选：“每个服务独立数据库”通常排除“所有服务共享一个中心数据库”；同步 RPC 与异步消息可作为跨服务通信的备选方案。

  • **冲突 / 覆盖：**强一致事务可能与高可用、低耦合目标冲突；安全合规要求可能覆盖单纯追求低延迟的方案。

**答题句：**记录决策关系可以帮助影响分析、解释权衡、发现冲突，并支撑架构演进。

知识出处：slides/09Architectural Decisions.pdf 第 46-47 页；本地 OCR：sources/slides-ocr/2026-05-27/pdftotext-triage/09Architectural_Decisions.txt:690-708。

# 二、讨论问答题

# 2025-11｜通用设计策略

**题目：**软件设计中的 通用设计策略（Generic Design Strategies） 是什么？为每个策略提供一个简明软件架构示例。

**参考回答：**按 slides/01_Introduction.pdf 第 24 页，可写六项：Abstraction / 抽象、Decomposition / 分解、Divide and Conquer / 分而治之、Generate and Test / 生成与测试、Iteration or Incremental Refinement / 迭代式增量细化、Reusable Elements or Reuse / 复用元素。

  • **Abstraction：**用支付接口隐藏支付宝、微信、银行卡等实现差异。

  • **Decomposition：**按课程、选课、订单、支付拆分职责。

  • **Divide and Conquer：**把迁移拆成网关接入、服务抽取、数据迁移、灰度发布几步。

  • **Generate and Test：**生成多个候选架构，用 ASR 场景比较性能、可用性和可修改性。

  • **Iteration：**在 ADD 中逐轮选择待分解元素并细化设计。

  • **Reuse：**复用 API Gateway、消息队列、容器平台和成熟模式降低风险。

知识出处：03 质量属性、ASR 与 ADD；sources/slides-ocr/2026-05-27/ocr-output/01-introduction/pages/page-24.txt。

# 2025-12｜微服务特性与 SOA 对比

**题目：**说明 微服务架构 的特点，并比较 微服务 和 SOA。

参考回答：微服务（Microservices） 强调围绕业务能力拆分小服务、服务自治、独立部署、独立数据边界、自动化运维、弹性伸缩和演进式设计。SOA（Service-Oriented Architecture） 更偏企业级服务集成、复用和治理，服务粒度通常更粗，常见做法包括服务契约、服务注册、集中治理和 ESB（Enterprise Service Bus，企业服务总线）。

  • **共同点：**都通过服务化和分布式协作降低系统耦合。

  • **差异：**微服务更强调小粒度、团队自治、独立发布和去中心化治理；SOA 更强调企业范围内的服务复用和治理一致性。

  • **代价：**微服务带来服务发现、链路追踪、分布式事务、配置和运维复杂度；SOA 可能因集中治理或 ESB 形成性能和组织瓶颈。

知识出处：04 架构模式演进与微服务。

# 三、设计题

# 2025-13｜DDD 代码评价与重构

**题目：**给定一个场景和一段现有设计代码：评价代码是否合理，违反了哪些 DDD 设计原则；再用 DDD 思路重新设计，给出设计过程和修改后的代码。

**参考回答：**这类题分两步：先评价代码违反哪些 DDD 设计原则，再按 05 页六步给出重构。评价时可以按“边界、模型、行为、一致性、依赖”检查。

  • **贫血模型（Anemic Domain Model）：**实体只有字段和 getter/setter，业务规则都堆在 Service / Manager / Controller 中，领域对象没有承载行为。

  • **聚合边界不清：**外部代码直接改聚合内部对象，或跨多个对象随意改状态，聚合根无法维护一致性边界。

  • **实体和值对象混用：**有身份连续性的对象应建成 Entity；只看属性值、可替换的概念更适合 Value Object。

  • **统一语言和限界上下文缺失：**命名只反映数据库表或技术层，没有体现业务词汇、领域事件和上下文边界。

  • **依赖方向错误：**领域层直接依赖数据库、框架或外部系统细节，破坏领域层与基础设施隔离，也容易违反 Dependency Inversion。

**重构写法：**按 适用性与痛点 → 统一语言与领域事件 → 限界上下文与上下文映射 → 战术建模 → 协作与落地 → 收益与代价 组织。代码展示时把核心规则放回聚合根方法，例如 Order.pay()、Order.cancel() 维护状态转换和金额不变量；应用服务只编排用例，Repository 加载和保存聚合，跨上下文协作用 Domain Event 或防腐层隔离。

**一句话收束：**DDD 重构不是把类改名为 Entity / Service，而是让模型边界、业务语言和代码行为对齐，由聚合根保护一致性，并把技术细节挡在领域层外。

知识出处：05 DDD、事件风暴与企业架构；DDD.md:52-75；sources/slides-ocr/2026-05-27/pdftotext-triage/11-12Domain-Driven_Design_-_Event_Storming.txt:397-425, 526-614, 833；题面来源：2025软件系统设计回忆.md:29-32。

# 2024 本课程回忆版：具体题目

**2024 刷题路线：**先做 2024-03 刺激-响应图、2024-05 4+1、2024-12 迁移设计；再集中背 ADD 流程、七类设计决策、DDD、企业架构。回答统一采用前面专题页的表达。

**使用方式：**以下内容把题目和参考回答放在一起；答案依据题面、原始课件、本地 OCR 与前面专题页整理，不是阅卷公布的标准答案。

# 2024-01｜软件架构师及其职责

**题目：**软件架构师是什么，写出其五种职责。

参考回答：软件架构师负责把业务目标、需求、质量属性和技术约束转化为可实施、可沟通、可验证的架构方案。按课件中的 Architecture Activities，五种职责可写：创建和选择架构、沟通架构、分析或评估架构、指导实施架构、确保实现与架构保持一致。

  • **展开写法：**创建/选择架构对应方案设计；沟通架构对应对齐涉众；分析/评估架构对应质量属性和风险评审；指导实施对应把设计落到代码和部署；保持一致对应架构治理和偏差纠正。

  • **可补充能力：**Liaison（联络）、Software Engineering（软件工程能力）、Technology Knowledge（技术知识）、Risk Management（风险管理）。

知识出处：02 核心概念与架构过程；softarch2025-review.txt。

# 2024-02｜通用设计策略

**题目：**说明软件设计中的 通用设计策略（Generic Design Strategies）。

**参考回答：**按 slides 可写六项：Abstraction / 抽象、Decomposition / 分解、Divide and Conquer / 分而治之、Generate and Test / 生成与测试、Iteration / Incremental Refinement / 迭代式增量细化、Reusable Elements / Reuse / 复用元素。

  • **答题提醒：**每项都要回到架构设计：抽象隐藏实现，分解划清职责，分而治之降低复杂度，生成与测试用场景验证候选方案，迭代细化逐轮处理 ASR，复用元素降低风险和成本。

  • **例子：**在线课程平台中，用接口抽象支付渠道，按课程/订单/支付拆服务，用 ADD 生成候选架构并通过性能与可用性场景测试。

知识出处：03 质量属性、ASR 与 ADD；sources/slides-ocr/2026-05-27/ocr-output/01-introduction/pages/page-24.txt。

# 补充题 15｜Generic Design Strategies in ADD

English prompt: Describe how generic design strategies are embodied in the Attribute-Driven Design (ADD) process.

题目：说明通用设计策略如何体现在 ADD / Attribute-Driven Design 过程中。

快速背诵：通用设计策略（生抽可迭代二分）在 ADD 中都有体现：ADD 通过分解系统元素、抽象高层结构、逐步迭代细化架构、生成并测试候选设计、按 Divide and Conquer / 分而治之 分轮满足 ASR，并复用已有模式和战术，最终形成满足架构显著需求的软件架构。

  • **生成与测试 / Generate and Test：**选择候选 tactics、patterns 和参考架构，再用质量属性场景、风险和权衡评审。

  • **抽象 / Abstraction：**先形成高层结构和接口，不急于陷入实现细节。

  • **可复用元素 / Reuse：**复用已有模式、战术、框架、中间件和基础设施。

  • **迭代式增量细化 / Iteration：**ADD 每轮处理一组 drivers，从整体到局部逐步细化。

  • **分而治之 / Divide and Conquer：**把复杂架构问题拆成可管理的迭代目标。

  • **分解 / Decomposition：**选择要精化的系统元素，并拆出子系统、模块、服务、接口和职责。

ADD 步骤的输入输出：

  1. **Review Inputs：**输入为设计目的、主要功能、质量属性、关注点和约束；输出为确认后的设计输入和驱动因素清单。

  2. **Establish Iteration Goal：**输入为 ASR、风险和优先级；输出为本轮迭代目标。

  3. **Choose Elements to Refine：**输入为当前系统和已有架构草图；输出为本轮要细化的系统元素。

  4. **Choose Design Concepts：**输入为本轮 drivers 和候选设计概念；输出为选定的 tactics、patterns、参考架构和选择理由。

  5. **Instantiate Elements：**输入为设计概念；输出为具体元素、职责、接口、关系和资源安排。

  6. **Sketch Views and Record Decisions：**输入为具体元素和关键选择；输出为架构视图、接口说明、ADR / 决策记录、约束和风险。

  7. **Analyze and Iterate：**输入为当前设计和质量属性场景；输出为风险、权衡、敏感点、是否达成本轮目标，以及下一轮输入。

知识出处：03 质量属性、ASR 与 ADD；slides/01_Introduction.pdf 第 24 页 Generic Design Strategies；slides/Designing Software Architectures - ADD 3.0.pdf。

# 2024-03｜互操作性与性能刺激-响应图

**题目：**画出 互操作性 和 性能 的刺激-响应图。

**参考回答：**质量属性场景统一写六要素：刺激源、刺激、环境、制品、响应、响应度量。互操作性强调不同系统之间正确交换和理解信息；性能强调在指定环境下响应时间、吞吐量或资源占用达到指标。

  • **互操作性示例：**外部支付系统发来合规请求 → 接口适配器完成协议/数据转换 → 返回双方都能解析的结果；响应度量可写“字段映射正确率 100%，错误码可追踪”。

  • **性能示例：**高峰期用户查询课程 → 课程服务处理请求 → 95% 请求在 200ms 内返回。

知识出处：03 质量属性、ASR 与 ADD；slides/02-04_Quality Attributes.pdf。

# 2024-04｜Layered Pattern 与 Multi-tier Pattern

**题目：**比较 Layered Pattern 与 Multi-tier Pattern 的差异。

参考回答：Layered Pattern / 分层模式 是逻辑职责组织，把系统划分为表现层、应用层、领域层、基础设施层等，并控制依赖方向；Multi-tier Pattern / 多层部署模式 是物理部署组织，把系统部署在客户端、Web 服务器、应用服务器、数据库服务器等不同节点上。

  • **Layered 收益：**关注点分离、可维护性和可测试性较好；代价是跨层调用可能增加间接性。

  • **Multi-tier 收益：**可以独立伸缩、隔离资源和部署；代价是网络通信、部署运维和故障诊断更复杂。

  • **一句话：**Layered 主要回答“代码职责怎么分”，Multi-tier 主要回答“运行节点怎么分”。

知识出处：04 架构模式演进与微服务。

# 2024-05｜4+1 视图与 UML

**题目：**写出 4+1 视图 中的四个视图，并简要描述。

**参考回答：**四个视图是 逻辑视图、开发视图、进程视图、物理视图，再用 场景 / 用例视图 作为 “+1” 贯通。UML 表达可写：用例图 表达场景，类图 表达逻辑视图，组件图 / 包图 表达开发视图，时序图 / 通信图 表达进程视图，部署图 表达物理视图。

知识出处：02 核心概念与架构过程；本页 2023-06 PlantUML 示例。

# 2024-06｜ADD 流程

**题目：**简述 ADD 的步骤流程。

参考回答：ADD 3.0（Attribute-Driven Design） 是围绕 ASR 和设计决策逐轮细化架构的方法。可按前面专题页统一写：驱动因素 → 待分解元素 → 设计概念 → 实例化 → 文档化 → 评审迭代。

  • **展开步骤：**确认目的与输入；选择本轮待分解元素；选择能满足 ASR 的设计概念；实例化元素、职责、接口和交互；文档化视图与决策；用场景评审并进入下一轮。

  • **例子：**在线课程平台迁移中，本轮选择选课/订单/支付子系统，设计概念选 API Gateway、按业务能力拆分、消息事件、容器部署和熔断降级，再用 P95 响应、故障隔离和回滚能力验证。

知识出处：03 质量属性、ASR 与 ADD；04 架构模式演进与微服务。

# 2024-07｜七类设计决策

**题目：**写出 七类设计决策。

**参考回答：**七类设计决策为：职责分配（Allocation of Responsibilities）、协调模型（Coordination Model）、数据模型（Data Model）、资源管理（Management of Resources）、架构元素映射（Mapping among Architecture Elements）、绑定时机决策（Binding Time Decisions）、技术选择（Choice of Technology）。

  • **在线课程例子：**EnrollmentService 管选课规则；支付成功发布 PaymentSucceeded；CourseDB / OrderDB 分离；选课服务高峰横向扩容并限流；服务分别部署到容器；支付渠道和限流阈值运行时配置；技术选择 API Gateway、消息队列、容器编排和链路追踪。

  • **答题提醒：**不要只背七个英文名，每类后面补一句“影响哪个 ASR、带来什么收益和代价”。

知识出处：03 质量属性、ASR 与 ADD。

# 2024-08｜微服务容器部署模式

**题目：**说明微服务分解中的 容器模式：上下文、需求、优势与限制。

参考回答：容器部署模式适用于服务数量较多、需要独立发布和弹性伸缩的微服务系统。需求包括运行环境一致、资源隔离、快速启动、自动化部署、横向扩容和故障恢复。

  • **优势：**镜像化交付、环境一致、资源利用率高、易于弹性伸缩和持续交付。

  • **限制：**引入容器编排、服务发现、网络治理、日志监控、状态数据管理和安全隔离复杂度。

  • **答题句：**容器不是微服务本身，而是支撑微服务独立部署和运行治理的一种部署实现方式。

知识出处：04 架构模式演进与微服务。

# 2024-09｜DDD 的一般过程

**题目：**说明 DDD 的一般过程。

**参考回答：**按 05 页六步组织：适用性与痛点 → 统一语言与领域事件 → 限界上下文与上下文映射 → 战术建模 → 协作与落地 → 收益与代价。

  • **怎么写：**先说明业务复杂、规则多变、沟通成本高时适合 DDD；再通过事件风暴找领域事件和命令；划分限界上下文；在上下文内部识别实体、值对象、聚合根、领域服务、领域事件和 Repository；最后说明应用服务、领域层和基础设施层的协作。

  • **收益与代价：**收益是统一语言、一致性边界清晰、可修改性更好；代价是建模成本、团队协作成本和过度设计风险。

知识出处：05 DDD、事件风暴与企业架构。

# 2024-10｜企业架构的基本功能

**题目：**说明 企业架构 的基本功能。

参考回答：企业架构 的基本功能是连接战略与实施，把业务、数据、应用、技术架构组织成可治理、可演进的蓝图。它帮助企业识别业务能力、规划系统支撑关系、减少重复建设、统一标准、指导投资和迁移路线。

  • **答题结构：**战略对齐 → 能力识别 → 蓝图设计 → 路线图和治理 → 实施反馈。

  • **与方法关系：**TOGAF 是企业架构框架；ADM 是 TOGAF 中推进架构开发的流程；CBM 是从业务能力拆业务组件的建模方法。

知识出处：05 DDD、事件风暴与企业架构；slides/10Enterprise_Architecture.pdf。

# 2024-11｜分层、SOA 与微服务比较

**题目：**从设计策略、优势与限制等角度比较 分层、SOA 和 微服务 架构。

参考回答：分层架构以职责分离和依赖方向控制提升可维护性；SOA以企业级服务集成、复用和治理为主；微服务以小自治服务、独立发布、独立数据边界和弹性运维为主。

  • **分层：**适合组织代码职责，限制是层间绕行、层级过厚和部署伸缩粒度粗。

  • **SOA：**适合企业应用集成和服务复用，限制是集中治理和 ESB 可能变重。

  • **微服务：**适合复杂业务快速演进和独立交付，限制是分布式事务、监控、配置、测试和运维复杂。

知识出处：04 架构模式演进与微服务。

# 2024-12｜在线课程平台迁移设计题

**题目：**在线课程平台从分层架构迁移至微服务：选择实现模式；比较 single-host、multi-host 和容器三种部署方式并推荐实验方案；设计包含分解、部署、数据迁移、关键里程碑与最终交付物的迁移方案。

**参考回答：**可按“ASR → 拆分 → 部署 → 数据迁移 → 里程碑 → 验证”写。高优先级 ASR 通常是高峰性能、支付故障隔离、可部署性、可回滚和数据一致性。实现模式可选择 Strangler Fig / 绞杀者路线：先用 API Gateway 接入新服务，逐步替换旧分层系统。

  • **分解：**按业务能力或限界上下文拆成 CourseService、EnrollmentService、PaymentService、UserService。

  • **部署比较：**single-host 简单但隔离和扩展差；multi-host 隔离更好但运维复杂；容器方案适合实验和持续交付，可复现、易扩展，但需要编排和监控。

  • **数据迁移：**先读旧库，逐步拆分 CourseDB / OrderDB / PaymentDB；用事件或同步任务保证过渡期一致性。

  • **里程碑：**边界识别 → 网关路由 → 新服务上线 → 数据迁移 → 监控告警和回滚 → 验收交付。

知识出处：04 架构模式演进与微服务；03 质量属性、ASR 与 ADD；slides/Designing Software Architectures - ADD 3.0.pdf。

# 2023 本课程回忆版：具体题目

**2023 刷题路线：**先做 2023-06 4+1 和 2023-12 Call Graph 两道画图题，再背 Broker / C&C / SOA，最后看 DDD、企业架构、微服务部署。

**使用方式：**以下内容将回忆题与参考回答放在一起，便于按题训练表达；答案依据题面、原始课件与本库专题整理，不是阅卷公布的标准答案。

# 2023-01｜软件架构的定义和重要性

**题目：**说明 软件架构 的定义和重要性。

参考回答：软件架构 是系统的一个或多个结构，包括 软件元素、元素的 外部可见属性 以及元素之间的 关系。重要性体现在：架构承载早期关键决策，影响质量属性，是涉众沟通媒介，也是一种可复用、可分析、可演进的抽象。

  • **考试写法：**定义先写“结构 + 元素 + 关系 + 外部可见属性”，再写“沟通、分析、约束实现、质量属性、复用”。

  • **不要写偏：**架构不是全部代码细节，也不是只画部署图。

知识出处：02 核心概念与架构过程。

# 2023-02｜需求、质量属性与 ASR

**题目：**说明 需求、质量属性 和 ASR 的区别。

**参考回答：需求（requirements）**描述系统需要满足什么，可分为功能需求、质量需求和约束；**质量属性（quality attributes）**描述系统要做到多好，例如性能、可用性、可修改性、互操作性；ASR（Architecturally Significant Requirement） 是显著影响架构的需求或约束。

  • **关系：**质量属性经常成为 ASR，但不是所有质量属性都显著影响架构；功能需求或业务/技术约束也可能是 ASR。

  • **判断：**如果一个需求会影响架构模式、职责分配、部署、数据模型、资源管理或技术选择，就应作为 ASR 处理。

知识出处：03 质量属性、ASR 与 ADD。

# 2023-03｜可用性与性能质量属性建模

**题目：**对 可用性 和 性能 进行质量属性建模。

**参考回答：**统一写 质量属性场景六要素：刺激源、刺激、环境、制品、响应、响应度量。可用性关注故障后能否继续服务或快速恢复；性能关注响应时间、吞吐量和资源占用。

  • **可用性例子：**服务节点故障，系统在降级环境中切换到备用实例，30 秒内恢复核心功能。

  • **性能例子：**高峰期用户发起查询，系统在正常运行环境下处理，95% 请求在 200ms 内返回。

知识出处：03 质量属性、ASR 与 ADD；slides/02-04_Quality Attributes.pdf。

# 2023-04｜DDD 战略设计与战术设计

**题目：**比较 DDD 中 战略设计 与 战术设计 的区别，并各举两个例子。

参考回答：战略设计关注业务边界和上下文协作，例如 子域、核心域、限界上下文、上下文映射、统一语言；战术设计关注上下文内部模型和代码落地，例如 实体、值对象、聚合、聚合根、领域服务、领域事件、Repository。

  • **战略例子：**把课程、选课、订单、支付划成不同限界上下文；用上下文映射说明订单与支付的协作关系。

  • **战术例子：**在订单上下文中设计 Order 聚合根；用 OrderPaid 领域事件通知后续履约。

知识出处：05 DDD、事件风暴与企业架构。

# 2023-05｜架构过程的输入与输出

**题目：**说明架构过程各阶段的输入与输出。

**参考回答：**架构过程可按 识别 ASR → 架构设计 → 文档化 → 评估 / 迭代 组织。输入包括业务目标、需求、质量属性、约束、涉众关注点、既有系统和技术环境；输出包括架构视图、接口、关键设计决策、决策理由、风险清单、质量属性验证结果和演进路线。

  • **阶段对应：**需求和关注点进入 ASR 识别；ASR 驱动设计概念选择；设计结果进入视图和文档；评估结果反馈到下一轮。

知识出处：02 核心概念与架构过程；03 质量属性、ASR 与 ADD。

# 2023-06｜4+1 Views 与 UML 画法

**题目：**说明 4+1 Views。

**参考回答：**4+1 视图包括 逻辑视图、开发视图、进程视图、物理视图 和 场景 / 用例视图。考试画图时建议用 UML：用例图锁定场景，类图表达逻辑职责，组件图 / 包图表达开发组织，时序图表达运行交互和并发，部署图表达物理节点。

知识出处：02 核心概念与架构过程；外部原始参考：[Kruchten 4+1 View Model](https://ics.uci.edu/~michele/Teaching/INF117/Krutchten 4 1View SWArch.pdf)。

# 4+1 视图 PlantUML 具体画法：在线课程平台示例

**使用方式：**考试中先用 +1 场景 锁定同一个业务故事，再分别画 逻辑视图、开发视图、进程视图、物理视图。下面每种视图都给出一种可直接照画的 PlantUML 结构。

# +1 场景视图：用例图
# 逻辑视图：类图
# 开发视图：组件图 / 包图
# 进程视图：时序图
# 物理视图：部署图

# 2023-07｜Broker 模式

**题目：**说明 Broker 模式的适用上下文、优点与缺点。

参考回答：Broker 适用于分布式组件需要解耦通信、动态定位和远程调用的场景。Broker 负责服务注册、查找、请求转发、协议适配或消息路由，使客户端不必直接知道服务端的位置和实现。

  • **优点：**位置透明、客户端和服务端解耦、可扩展、服务替换更容易。

  • **缺点：**增加一次中间转发，可能带来性能开销、单点风险、调试复杂度和治理成本。

知识出处：04 架构模式演进与微服务。

# 2023-08｜C&C 与 SOA

**题目：**说明 C&C 的本质，并以 SOA 为例介绍。

参考回答：C&C（Component-and-Connector） 描述运行时组件与连接器：组件执行计算或存储职责，连接器负责调用、消息、事件、数据流、同步等交互。SOA（Service-Oriented Architecture） 中，组件是可调用服务，连接器可以是服务调用、消息通道、服务网关或 ESB（Enterprise Service Bus）。

  • **SOA 要点：**服务契约、松耦合、服务复用、服务组合、治理和监控。

  • **代价：**网络故障、延迟、服务治理复杂度，以及集中式 ESB 可能形成瓶颈。

知识出处：04 架构模式演进与微服务；外部原始参考：SEI UML/C&C 报告。

# 2023-09｜DDD 聚合模式的价值

**题目：**与面向对象设计对比，分析 DDD 中引入 聚合模式 的价值。

参考回答：聚合（Aggregate） 是一组需要保持业务一致性的领域对象边界，聚合根（Aggregate Root） 是外部访问聚合的唯一入口。与普通面向对象中对象可被到处直接修改相比，聚合让一致性规则集中在边界内，由聚合根维护不变量。

  • **价值：**减少跨对象随意修改，降低跨事务复杂度，保护业务约束，使模型边界和代码边界更一致。

  • **例子：**订单聚合内由 Order 控制支付、取消、明细变更；外部不能绕过 Order 直接修改订单项状态。

知识出处：05 DDD、事件风暴与企业架构；slides/11-12Domain-Driven Design - Event Storming.pdf。

# 2023-10｜企业架构的一般过程

**题目：**说明 企业架构 的一般过程。

**参考回答：**企业架构过程可以写成：明确战略与业务目标 → 识别业务能力和痛点 → 建立业务/数据/应用/技术架构蓝图 → 分析差距 → 制定路线图和迁移计划 → 实施治理 → 持续评估和演进。

  • **TOGAF / ADM 关系：**TOGAF 是企业架构框架，ADM 是 TOGAF 中推进架构开发的迭代流程。

  • **CBM 作用：**CBM 从业务能力出发拆分业务组件，可用于识别业务边界和系统支撑关系。

知识出处：05 DDD、事件风暴与企业架构；slides/10Enterprise_Architecture.pdf。

# 2023-11｜微服务部署问题与模式

**题目：**说明 微服务部署问题、相关上下文及可用模式。

参考回答：

  • 问题：微服务部署问题的核心是如何把大量可独立发布、可独立伸缩的服务实例可靠地运行起来，并处理隔离、资源、配置、发现、监控、升级和回滚。

  • 上下文：

    • 系统由多个可独立发布的服务组成。

    • 每个服务可能用不同技术栈、依赖和运行时。

    • 服务数量多，实例变化频繁。

    • 需要支持快速发布、灰度升级、弹性扩缩容和故障隔离。

    • 运维复杂度显著高于单体或简单分层系统。

  • 部署模式：

    • Single-host：多个服务部署在一台主机上。优点是简单、成本低、部署快；缺点是 隔离弱，单机故障影响大。

    • Multi-host / VM：服务部署到不同主机或虚拟机。优点是 故障域更清晰，便于独立伸缩；缺点是资源开销和运维工作增加。

    • Container / Platform：每个服务打包成容器，由平台编排、扩缩容、滚动更新。优点是支持 独立部署、弹性伸缩、环境一致性、快速回滚；缺点是需要处理 编排、网络、镜像治理、监控和故障定位。

    • Serverless：适合事件触发、运行频率不稳定的能力。优点是弹性强、少管基础设施；缺点是可能有 冷启动、调试困难、平台绑定。

知识出处：04 架构模式演进与微服务。

# 2023-12｜Call Graph 架构设计画图题

**题目：**针对抽取程序 call graph 的程序：选择一种架构 pattern 并说明理由与高优先级质量属性；用 module view 描述职责分配；用 C&C 风格画出 runtime elements。

**参考回答：**可选 Pipe-and-Filter 或数据流型 C&C。高优先级质量属性可写 可修改性、性能、可测试性。模块视图按 Source Reader、Parser、Resolver、Graph Builder、Store、Exporter 分职责；运行视图画 Source → Parser / AST → Resolver → Graph Builder → Store / Exporter 的数据流。

  • **选择理由：**Call Graph 抽取天然是逐步转换流程，Filter 可独立替换和测试，Pipe 表达中间结果传递。

  • **权衡：**流水线清晰，但全局错误处理、增量分析缓存和性能瓶颈需要额外设计。

# 画图示例：C&C 运行视图

  • **图上元素：**运行元素是 Parser、Resolver、Builder、Store、Exporter；连接器是数据流、查询请求和结果返回。

  • **写图后解释：**说明每个元素职责、连接器语义，以及该结构如何支撑可修改性和性能。

# 知乎本地存档补充：2015-2019 练题线索

**补充线索读法：**这一节来自知乎本地存档和外部复习资料，适合用来补 题型覆盖，不要当作本课程标准答案。优先吸收反复出现的题型：4+1 视图、ASR、ADD、Layered vs Multi-tier、SOA / 微服务。

**来源边界：**本节来自用户提供的知乎页面本地存档《南京大学软件学院-2024-软件体系结构（研究生）期末复习参考》，归档副本位于 sources/supplemental/2026-05-27/zhihu-13472495294-software-architecture-review.mhtml；用于交叉核验的 EagleBear2002 HTML 也保存在同一归档目录。本课程范围与标准答案仍以老师纪要、扫描文档和原始 slides 为准。

# 2017 / 2019｜4+1 视图绘图

**题目线索：**描述 4+1 视图，并掌握绘图。

**参考回答：**按 场景 / 用例图 → 逻辑视图 / 类图 → 开发视图 / 组件图或包图 → 进程视图 / 时序图 → 物理视图 / 部署图 组织。关键不是背五个名字，而是用同一业务场景把五张图贯通。

  • **答题句：**不同视图服务不同涉众和关注点，+1 场景用于验证四个视图是否共同支撑核心用例。

  • **复习入口：**具体 UML 画法见本页 2023-06。

# 2015 / 2017｜软件架构过程的输入与输出

**题目线索：**描述软件架构过程的一般活动、主要输入和输出。

**参考回答：**按 识别 ASR → 架构设计 → 文档化 → 评估/迭代 回答。输入是业务目标、需求、质量属性、约束、涉众关注点和技术环境；输出是架构视图、接口、设计决策、决策理由、风险、验证结果和后续演进计划。

  • **提分点：**把“质量属性场景”和“架构决策”写进输入输出之间的转换过程，说明架构不是一次性文档，而是迭代决策过程。

# 必考标注｜质量属性刺激-响应建模

**题目线索：**用“刺激-响应”图进行质量属性场景建模。

**参考回答：**严格写六要素：刺激源、刺激、环境、制品、响应、响应度量。响应度量必须可测试，例如 P95 响应时间、恢复时间、错误率、兼容字段比例、修改所需人日。

  • **性能：**高峰用户发起请求，系统在正常环境下处理，95% 请求 200ms 内返回。

  • **可用性：**节点故障后系统切换备用实例，30 秒内恢复核心功能。

  • **互操作性：**外部系统发来请求，适配器完成协议/数据转换并返回可解析结果。

# 2017 / 2019｜ASR 的定义与识别

**题目线索：**什么是 ASR；列出提取和识别 ASR 的来源与方法。

参考回答：ASR（Architecturally Significant Requirement） 是显著影响架构的需求或约束。来源包括需求文档、业务目标、质量属性场景、涉众访谈、既有系统、技术环境、法规和组织约束。

  • **识别方法：**看它是否会影响架构模式、职责分配、数据模型、部署、资源管理、技术选择或接口边界。

  • 例子：“高峰期 P95 <= 200ms”会影响缓存、扩容和数据访问；“支付故障不能影响选课”会影响服务拆分和故障隔离。

# 2015 / 2017 / 2019｜为何使用不同架构视图

**题目线索：**为什么用不同视图文档化软件架构；列出四种视图及目的。

**参考回答：**使用不同视图是因为涉众关注点不同，单一视图无法同时表达职责、运行交互、部署和代码组织。可写 逻辑视图 描述领域职责，开发视图 描述代码模块，进程视图 描述运行交互和并发，物理视图 描述部署节点，再用场景视图验证。

  • **关键词：**关注点分离、涉众沟通、复杂性控制、架构验证。

# 2018｜Layered Pattern 与 Multi-tier Pattern

**题目线索：**比较 Layered Pattern 与 Multi-tier Pattern。

参考回答：Layered 是逻辑职责分层，关注依赖方向和可维护性；Multi-tier 是物理部署分层，关注节点分布、伸缩和网络通信。

  • **Layered 例子：**表现层、应用层、领域层、基础设施层。

  • **Multi-tier 例子：**浏览器、Web Server、Application Server、Database Server。

  • **一句话：**分层回答“代码职责怎么组织”，多层回答“运行时部署在哪里”。

# 2018｜ADD 过程

**题目线索：**描述 ADD 过程。

**参考回答：**按本库统一写 ADD 3.0：驱动因素 → 待分解元素 → 设计概念 → 实例化 → 文档化 → 评审迭代。如果外部存档写八步，可理解为旧版或更细拆分，本页答题优先采用前面专题页的统一表述。

  • **展开：**确认需求和 ASR；选择待分解元素；选择设计概念；分配职责、定义接口和交互；记录视图与决策；用场景评审并继续迭代。

# 2015｜SOA 原则及质量属性影响

**题目线索：**描述 SOA 基本原则及其对互操作性、可伸缩性、安全性的影响。

参考回答：SOA（Service-Oriented Architecture） 的基本原则包括服务契约、松耦合、服务抽象、服务复用、服务组合、治理和可发现性。它通过标准契约和服务治理提升互操作性，通过服务拆分和部署策略支持伸缩，但也引入安全边界、访问控制、审计和网络暴露风险。

  • **质量属性写法：**互操作性看协议和数据契约；可伸缩性看服务粒度和部署；安全性看身份认证、授权、审计和网关策略。

# 2019｜微服务与 SOA 的异同

**题目线索：**比较 微服务 与 SOA 的异同。

**参考回答：**共同点是都采用服务化和分布式协作来降低系统耦合。差异在于：微服务更强调小粒度、围绕业务能力拆分、服务自治、独立部署、独立数据边界和自动化运维；SOA更强调企业级服务复用、服务契约和集中治理，服务粒度通常更粗。

  • **答题收束：**微服务不是“更小的 SOA”这么简单，它同时改变了服务粒度、团队边界、数据边界和交付方式。

# 本地作业题转化为训练题

**使用方式：**本节不是新增考试范围，而是把本地作业中可迁移的训练方法转成 06 页答题模板。遇到题目时，优先回到 ASR → tactic / pattern → 结构图 → 权衡 → 验证。

  1. **质量属性场景题：**为在线报价服务、订单系统或微服务故障场景写一份 可用性 / 性能 场景。答案必须包含 刺激源、刺激、环境、制品、响应、响应度量。示例：支付服务实例故障时，监控组件触发故障转移，订单系统在降级环境中 30 秒内恢复核心支付状态查询。

  2. **Tactics 权衡题：**从可用性、可伸缩性、可部署性或安全性中选一个质量属性，至少写两种 tactics，再说明收益、代价和影响的其他质量属性。示例：冗余和心跳提升可用性，但增加资源成本和一致性处理；缓存提升性能，但可能引入数据过期风险。

  3. **Pattern 选择题：**把作业里的“策略选择”迁移成考试语言：先写 ASR，再选择 Layered、Broker、Pipe-and-Filter、SOA、Microservices 等 pattern，并解释 pattern 内部组合了哪些 tactics。

  4. **设计决策题：**用 七类设计决策 检查答案是否完整：职责分配、协调模型、数据模型、资源管理、架构元素映射、绑定时间、技术选择。每类至少能给一个当前题目的例子。

  5. **画图训练：**质量属性题画刺激-响应链；Call Graph 题画 Pipe-and-Filter；ATM 题画 Three-tier；DDD 题画限界上下文、聚合与领域事件；微服务迁移题画 API Gateway、服务、数据库和部署节点。

  6. **迁移到考试范围：**如果作业材料出现 AI 扩展或工程背景，保留其中的质量属性、tactics、pattern、部署和验证方法；不要把作业特定背景当成必考结论。

知识出处：03 质量属性、ASR 与 ADD；04 架构模式演进与微服务；本地 slides/作业/Assignment1-522025320053-何乐阳.tex 与 slides/Task2_Tactics.md。

# 考前自测

  • [ ] 不用资料写出质量属性场景六要素与一个具体例子

  • [ ] 画出 4+1 或 SOA/微服务对比骨架，并说明关注点

  • [ ] 按“问题、选择、权衡、验证”写一份架构决策答案

  • [ ] 做一题 DDD 重构：识别聚合、根、事件与服务职责

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