2026 年软件系统设计考题解答（回忆版）¶

本页面整理自历年考题中的 2026 年研究生回忆版，原卷为英文，以下为回忆的中文翻译及参考解答。

一、简答题（6分一题，共10题）¶

1. 请给出 Software Requirements、Quality Attributes 和 ASR 的区别与联系¶

软件需求（Software Requirements）：包含系统需要满足的所有要求，通常分为功能需求、质量属性（非功能需求）和约束。
质量属性（Quality Attributes）：软件系统的一项可衡量或可测试的属性，用于表明系统满足利益相关者需求的程度（如性能、可用性、可修改性等）。
ASR（Architectural Significant Requirements，架构攸关需求）：指对软件架构产生深远影响的需求。它可以是功能需求、质量属性或业务约束。
区别与联系：ASR 是系统所有需求的一个子集。并不是所有的需求都会影响架构设计，只有那些影响架构决策的需求才被称为 ASR。很多情况下，ASR 主要是由质量属性驱动的。

参考课件：slides/2026SUG_SysArch1_introduction.pdf，slides/Lecture 01 - Attributes Driven Design.pdf

2. 给出 6 个通用架构策略并结合具体例子讲解它们在架构设计中如何运用¶

六种通用设计策略（口诀：生抽可迭代二分）： 1. 分解（Decomposition）：将大问题拆解为小问题。例如将一个复杂的电商系统分解为订单、库存、支付等独立的微服务。 2. 抽象（Abstraction）：隐藏实现细节，提取共性。例如在设计模式中使用接口或抽象类来隔离具体实现。 3. 分而治之 / 逐步求精（Divide and Conquer / Stepwise Refinement）：分离关注点分别解决。例如分别对前端展示、后端业务逻辑和底层数据访问进行设计。 4. 生成与测试（Generate and Test）：提出初步架构并进行评估。例如设计出一种高并发架构草案，然后通过原型测试（Prototype）其吞吐量是否满足性能需求。 5. 迭代（Iteration）：不断循环细化设计。例如在 ADD（属性驱动设计）中，通过多次迭代，逐步将所有 ASR 映射到架构元素上。 6. 复用元素（Reuse of Elements）：使用已经被验证的设计结构。例如在处理高可用的需求时，直接复用现有的“主从冗余（Active-Passive）”架构模式。

3. 如何建模质量属性场景，并用刺激响应图画出可用性和可修改性的场景¶

建模质量属性场景需要包含六个部分： 1. 刺激源（Source of stimulus）：谁或什么产生了刺激。 2. 刺激（Stimulus）：发生的条件或事件。 3. 制品（Artifact）：系统被刺激作用的部分。 4. 环境（Environment）：刺激发生时系统所处的状态。 5. 响应（Response）：系统如何应对刺激。 6. 响应度量（Response measure）：如何测试和衡量响应的好坏。

可用性（Availability）场景刺激响应示例（描述说明）： - 刺激源：内部硬件 - 刺激：服务器崩溃 - 环境：系统处于正常运行状态 - 制品：Web 服务器进程 - 响应：系统检测到故障，切换到备用服务器并记录日志 - 响应度量：系统宕机时间不超过 1 分钟

可修改性（Modifiability）场景刺激响应示例（描述说明）： - 刺激源：开发人员 - 刺激：想要添加一种新的支付方式 - 环境：设计阶段 / 开发阶段 - 制品：系统结算模块 - 响应：开发人员修改代码，测试并集成，不影响核心订单流 - 响应度量：在 2 人天内完成修改并上线，且不产生新的 Bug

参考课件：slides/2026SUG_SysArch2_quality attributes.pdf

4. 给出 pattern 和 tactic 的区别与关系，并给出两个 pattern 具体例子及其关联的若干 tactic¶

战术（Tactic）：是控制单一质量属性响应的基础设计决策。战术更加细粒度和具体，直接针对某一种具体的质量属性（如可用性的 ping/echo 战术）。
模式（Pattern）：是针对特定情境下重复出现的问题的经验解决方案。模式通常更大、更复杂。
关系：一个架构模式通常包含了多个战术的组合。战术是模式的组成部分，模式打包了战术来解决更全局的结构维度的架构问题。

具体例子： 1. Model-View-Controller (MVC) 模式： - 关联战术：降低耦合（Reduce Coupling）、增加语义连聚（Increase Semantic Coherence）、限制通信路径（Restrict Communication Paths）—— 提升可修改性。 2. 主动-被动冗余（Active-Passive Redundancy）模式： - 关联战术：心跳检测（Heartbeat）或 Ping/Echo 故障检测、状态同步（State Synchronization）、异常转移/接管（Failover）—— 提升可用性。

5. 请给出架构设计的主要 process 步骤，以及每个步骤的 input & output¶

架构设计的一般过程（ADD 视角的通用简化提炼过程）：

识别与分析架构攸关需求（Identify ASRs）
Input：业务目标、原始需求规格说明书、约束。
Output：架构攸关需求（ASR）列表及其优先级。
架构设计（Architecture Design / Synthesis）
Input：ASRs 列表。
Output：候选架构设计决策、架构元素的结构草图（Sketches）。
架构文档化（Architecture Documentation）
Input：架构结构草图和设计决策。
Output：包含多个视图的正式架构描述文档（Architecture Document）。
架构评估（Architecture Evaluation，如 ATAM）
Input：架构说明文档、ASRs 列表。
Output：架构评估报告（发现的风险、敏感点和权衡点）。

参考课件：slides/Lecture 01 - Attributes Driven Design.pdf

6. 相比较于 Object-Oriented-Design，分析 introducing the Aggregate pattern of Domain-Driven-Design 的价值¶

在面向对象设计（OOD）中，对象之间往往可以具有任意的网状引用关系。这在复杂业务系统中容易导致数据一致性失效，因为任何外部对象都可以修改该对象内部的状态，业务规则和事务边界难以约束。

DDD 引入聚合（Aggregate）模式的价值： 1. 定义了一致性边界和事务边界：聚合将一组相关的领域对象作为一个整体来对待，保证了在对聚合内数据进行修改时，业务规则（Invariants）始终得以维护。 2. 降低了系统耦合与对象引用的复杂性：外部对象不能直接持有聚合内部实体（Entities）的引用。只能通过聚合根（Aggregate Root）与该聚合进行交互，从而隐藏并保护了聚合的内部实现。 3. 并发控制与加锁粒度优化：在进行数据库变更时，只需要对聚合根对象上锁，避免了为了保证数据一致性而去锁定过多无关的表。

7. 为什么在文档化架构设计时需要不同的视图？请给出 4 个 example views 的 name and purpose¶

为什么需要不同的视图：一个大型软件系统非常复杂，单一的图表或模型无法满足不同利益相关者（Stakeholders）的安全、部署、功能、性能等诸多诉求。不同的视图能够分离关注点（Separation of Concerns），使得开发人员、项目经理、测试人员、运维人员等都能从自己关心的角度理解架构。

四种示例视图（基于 4+1 视图模型）及其作用： 1. 逻辑视图（Logical View）： - 作用：主要展示系统的功能需求，描述系统内部的模块或类如何划分。重点面向开发人员。 2. 过程视图（Process View）： - 作用：展示系统的并发、同步和性能等动态行为特征，描述系统的进程和线程设计。重点面向系统集成者。 3. 开发视图（Development View）： - 作用：描述软件在开发环境中的静态组织结构，如目录结构、包（Packages）和组件等。重点面向程序员和配置管理员。 4. 物理 / 部署视图（Physical / Deployment View）： - 作用：描述软件到硬件的映射关系，展示拓扑结构、通信网络和硬件节点。重点面向系统运维人员和系统工程师。

8. 请给出微服务系统中的 4 个 architectural elements 及其各自的 roles¶

微服务架构中的架构元素（Architectural Elements）指的是该架构体系中扮演重要角色、行使独立职责的核心组件。（注：不仅限于拆分模式等设计理念，通常指代服务治理环境中的运行时或设计时组件元素）

API 网关（API Gateway）：
Role：作为单一的系统入口，负责路由请求到对应的微服务，并处理跨领域关注点（如认证、限流、日志等）。
服务注册与发现中心（Service Registry & Discovery）：
Role：维护当前可用微服务实例的网络位置，当服务实例上线或下线时动态更新状态，允许其他服务查找和调用彼此。
微服务实例（Microservices）：
Role：系统的业务载体，每个服务封装了一项独立的业务能力，拥有自己的数据库，可独立开发、部署和扩展。
事件总线 / 消息中间件（Message Broker / Event Bus）：
Role：处理服务之间的异步通信与事件分发，降低服务间的直接耦合度，提升系统的响应能力。

(若结合题目中学生提及的“断路器”、“配置中心”、“数据库”等，也均属于微服务体系的合法组件。)

参考课件：slides/Microservices Patterns.pdf

9. 请给出 Event-Driven 架构的 basic idea 及其在质量属性上的 trade-offs¶

Basic Idea：系统行为由对事件（Event）的产生、检测和响应驱动。在这种体系中，事件发布者（Producer）仅仅是将事件抛出给中间件或总线，它并不知道也不关心有哪些事件消费者（Consumer）接收它。整个通讯是异步的、解耦的。

质量属性上的权衡（Trade-offs）： - 优势（Pros）： - 极高的可修改性（Modifiability）和可扩展性（Scalability）：由于发布者和消费者高度解耦，添加新的事件消费者无需修改现有的发布者。 - 性能/响应性（Performance）：将长时间运行的任务异步化，能够更快地响应客户端请求。 - 劣势（Cons）： - 可测试性和可调试性差（Low Testability）：由于异步和解耦的特点，跟踪业务流向或复现错误变得十分困难。 - 数据一致性问题（Data Consistency）：无法像单体应用那样使用强一致性的本地事务，往往需要牺牲即时一致性来换取最终一致性（Eventual Consistency）。

10. 请给出企业架构中的 4A，并说出他们之间的 relationship¶

企业架构（EA, Enterprise Architecture）通常包含四个核心架构层（4A）： 1. 业务架构（Business Architecture, BA）：定义企业的业务战略、组织结构和关键业务流程。 2. 数据架构 / 信息架构（Data Architecture, DA）：描述企业逻辑和物理数据资产及其管理方式。 3. 应用架构（Application Architecture, AA）：提供要部署的各个应用系统的蓝图，描述它们的交互方式及其与核心业务流程的联系。 4. 技术架构（Technology Architecture, TA）：描述支撑业务、数据和应用服务部署的逻辑软件和硬件环境（网络、服务器、基础设施等）。

它们之间的关系：这四个架构从上到下存在着驱动与支撑（Drive & Support）的关系。 - 业务架构（BA）是源头，它驱动着数据架构（DA）和应用架构（AA）的设计。 - 数据架构（DA）和应用架构（AA）互相依存，应用产生或消费数据，通过软件来支撑具体业务流程的运转。 - 技术架构（TA）位于底层，它负责为上层的数据架构和应用架构提供平台、基础设施及软硬件运行支撑。

二、分析论述题（10分一题，共20分）¶

1. 简述 7 种 Design Decision，并结合 binding time 选择分析其对质量属性的影响¶

在架构设计中，常见的七种基本类别设计决策包括： 1. 职责分配（Allocation of Responsibilities）：识别出需要履行的职责并分配组装到元素上。 2. 协调模型（Coordination Model）：确定系统元素如何交互（协议、事件、异步或同步）。 3. 数据模型（Data Model）：确定系统将产生持久性管理哪些数据结构和存储形式。 4. 资源管理（Management of Resources）：管理并发资源、硬件、网络和数据库连接。 5. 架构元素映射（Mapping among Architecture Elements）：将不同视图中的元素相互映射关联。 6. 绑定时间决策（Binding Time Decisions）：决定软件实体变更是何时固定下来的（即绑定时间）。 7. 技术选择（Choice of Technology）：选择操作系统、框架、开发语言等。

Binding Time（绑定时间）的选择及其对质量属性的影响： - 设计时（Design Time） / 编码时（Compile/Development Time）：早期的绑定意味着硬编码或早期的架构决策。 - 影响：这种绑定限制了灵活性和可修改性（Modifiability），但由于变化少、结构确定，具备较高的性能（Performance）和可测试性（Testability）。 - 构建时（Build Time） / 部署时（Deployment Time）：通过配置文件或打包脚本改变系统行为。 - 影响：系统在部署时具备了环境适应能力，对客户特定的部署需求提升了可修改性，对开发期的核心逻辑不产生侵入。 - 运行时（Runtime）：如插件加载、运行时配置修改。 - 影响：提供最大的灵活性和可修改性（Modifiability，如高可用性场景的热插拔）。但极其动态的绑定机制降低了性能（解析或反射的额外开销），并且因为状态过于不可预测而显著降低了系统可测试性（Testability）与可靠性。

2. 软件架构演进（以大学生选课系统为例：C/S → 三层/分层 → SOA）¶

问题拆解：

（1）C/S的上下文（Context）及其解决的问题： 在最早期（主机/终端时代），由于计算能力全部集中在服务端，客户端只是显示器，系统的承载能力低下。 C/S（Client-Server）架构解决了这个问题。它充分利用了局域网普及和当时 PC 时代个人计算机日益提升的计算能力，将界面的渲染、用户的基本逻辑校验等“前台工作”交给客户端（Client）来做，而将核心的数据库查询操作交给服务端（Server），以此提升了系统的整体性能及响应速度。

（2）C/S在系统庞大后的弊端及为何向分层演进？ 当选课系统变庞大、“秒杀式抢课”和复杂的排课策略出现后，C/S 架构暴露出两大问题： - 胖客户端（Fat Client）维护灾难：如果业务逻辑写在客户端，一旦有业务更新，哪怕只是变更了一项选课策略，都需要所有学生重新下载并升级客户端； - 组件紧耦合带来低业务复用性（Business Reuse）：客户端和数据库通常产生深层绑定，缺乏一个中间层的协调。 向三层/分层（Layered）演进：通过将应用程序彻底划分为表示层（UI）、业务逻辑层（BLL）和数据访问层（DAL），能够使得每层关注自己的工作：更改底层数据库无需改前端，业务逻辑也可在服务端集中运行和分发。从而大大提高了可维护性、可修改性和业务代码的可复用性。

（3）分层的局限及为何演进到 SOA？ 分层架构在单系统或同一技术栈（比如全用 Java 或全用 C#）的团队中极大地提升了效率。但随着大学信息化的扩张，选课系统需要与外部系统相连（例如教务处的排考系统、一卡通计费系统等），此时分层架构的局限显现：其代码层面的接口仍然具有很强的平台绑定性，跨语言、跨组织集成变得非常困难。这就促成了SOA（面向服务架构）的演进。在 SOA 下，粗粒度的业务逻辑（如“查询某课容量”、“冻结某些费用”）被打包成标准化的服务（如基于 SOAP、WSDL 的 Web 接口），通过企业服务总线（ESB）进行全组织范围内的无缝交互。它消除了语言壁垒，使得企业级跨部门协作的互操作性（Interoperability）达到极致。

三、设计题（DDD及领域事件相关，20分）¶

应用场景背景：大学里的实验耗材采购与申请平台。该平台允许处理申请耗材、审批、采购并入库等核心领域事件。

Task 1: 整理领域事件流（Event Flow）及其分支（10分）¶

要求用英文过去时态动词并且给出 5-7 个主流程事件，在分支处理被拒绝或库存充足的情况。

主流程领域事件流（Happy Path，库存不足需要采购）： 1. RequisitionSubmitted (领料申请已提交) 2. RequisitionApproved (申请已通过审批) 3. PurchaseOrderIssued (采购单已签发) 4. OrderAcceptedBySupplier (供货商已接单) 5. ConsumablesWarehoused (耗材已入库) 6. ConsumablesChecked (已完成清点与验收)

分支与扩展流（Extend Flow）： - If approval is rejected by the approver：从 RequisitionSubmitted 之后分叉 -> RequisitionRejected (领料单被驳回)。 (Relationship: Rejecting a submitted requisition terminates the normal requisition flow.) - If inventory is sufficient (库存充足)：从 RequisitionApproved 之后分叉 -> 不进入采购流程，而是触发 InventoryDeducted (库存已扣减) -> ConsumablesDistributed (耗材已发放)。 (Relationship: When approved and inventory is adequate, fulfillment skips purchasing and proceeds to distribution.) - If the supplier refuses to accept the order：从 PurchaseOrderIssued 之后分叉 -> OrderRejectedBySupplier (供应商拒绝接单)。 (Relationship: A rejection by the supplier causes the purchase order to abort, requiring alternative sourcing.)

Task 2: 事件/策略提取及热点分析（5分）¶

选择 Task 1 中的 2 个领域事件，撰写事件、触发条件、操作人、响应策略及识别一个热点问题（Hotspot）。

领域事件 (Event)	触发条件 (Trigger Condition)	操作人 (Actor)
`RequisitionSubmitted`	用户在表单中填写了需要申领的实验耗材详情并确认提交。	学生/教师 (Applicant)
`ConsumablesWarehoused`	实物耗材抵达仓库，仓库管理员更新系统并完成登记入库。	仓库管理员 (Warehouse Admin)

策略及流转 (Policy)： “当 RequisitionSubmitted 事件 occurs 时，它将导致触发一个要求审批的 AssignToApproverCommand 命令，进入审批阶段。” “当 ConsumablesWarehoused 事件 occurs 时，它将导致触发一个通知系统的 NotifyApplicantEvent 来让申请人准备提取。”
识别热点（Hotspot for Expert Discussion）：何种类型的耗材（如危险化学品或非常昂贵的仪器）在被申请时不能由普通导师审批，而是需要触发特殊的系统工作流转交至专门的资质审核委员会？这是一个复杂的业务知识，需要领域专家介入讨论。

Task 3: 聚合设计（Aggregate Design, 5分）¶

画出聚合边界、标注名称及两个关联事件

聚合名称：ConsumableRequisition (耗材申请聚合)
聚合根 (Aggregate Root)：Requisition (领料申请单主体)
聚合边界内的实体/值对象：RequisitionItem (申请明细条目), RequisitionStatus (申请状态枚举)。
包含或强相关的两个至少事件是：
RequisitionSubmitted （聚合创建或流转初始状态发出）
RequisitionApproved （聚合接收审批指令后，状态发生改变发出）

参考提示：这是一套典型的基于事件风暴（Event Storming）过程的设计题目考法，在回答时紧扣 DDD（领域驱动设计）以事件溯源（过去时）、聚合一致性角度出发即可。