回忆卷答案

说明：以下答案按本课程现有笔记、PPT 和复习课重点整理。DDD Aggregate 那道题按你的要求暂不展开。

一、简答题

1. Difference and relationship of software requirements, quality attributes and ASR

软件需求是最宽泛的概念，包括功能需求、质量需求和约束。

  • Functional Requirements：描述系统必须做什么，例如用户提交申请、审批耗材申请、查询库存。
  • Quality Requirements / Quality Attributes：描述系统做得多好，例如 2 秒内响应、99.9% 可用、3 小时内完成修改。
  • Constraints：限制架构师设计自由度，例如必须使用指定数据库、必须部署在校内服务器。

ASR = Architecturally Significant Requirement，架构显著需求。ASR 是会对架构产生重大影响的需求。如果没有这个需求，系统可能会采用明显不同的架构设计。

三者关系：

Software Requirements
  ├── Functional Requirements
  ├── Quality Requirements
  └── Constraints

ASR 是其中对架构有显著影响的子集。

质量属性通常是 ASR 的重要来源，但不是所有质量属性都一定是 ASR。ASR 也不只包括质量属性，还可能包括关键功能、关键约束和高风险需求。

2. Generic design strategies and examples

6 个通用架构设计策略：

Strategy 中文 架构设计中的应用例子
Abstraction 抽象 用 Repository 接口隐藏数据库访问细节，业务层只依赖抽象接口
Decomposition 分解 将电商系统拆成用户、商品、订单、库存、支付、物流等模块或服务
Divide and conquer 分而治之 把复杂下单流程拆成创建订单、锁库存、支付、发货、通知等子问题
Generation and test 生成并测试 为高可用提出 active redundancy 和 passive redundancy 等候选方案，再分析比较
Iteration 迭代 ADD 中每轮处理一组 drivers，逐步完善架构
Reuse 复用 复用 MVC、分层架构、微服务模式、消息队列、Spring Boot 等成熟方案

在 ADD 中的体现：

  • Decomposition：Step 3 选择元素并逐步分解。
  • Abstraction：用模块、组件、接口抽象隐藏细节。
  • Divide and conquer：Step 2 每次选择一组 drivers，把问题拆成可处理的子问题。
  • Generation and test：设计决策是 hypothesis，Step 7 分析并修正。
  • Iteration：ADD 通过多轮迭代逐步完善架构。
  • Reuse：Step 4 使用参考架构、模式、战术、框架。

3. Model quality attribute scenarios; draw availability and modifiability scenarios

质量属性场景是描述质量需求的标准模板。一个质量属性场景包括六个部分：刺激源、刺激、受影响制品、环境、响应和响应度量。

Source of Stimulus -> Stimulus -> Artifact
                         |
                    Environment
                         |
                     Response -> Response Measure

Availability 场景：

Element 内容
Source Heartbeat 监视器
Stimulus 服务器无响应
Artifact 进程
Environment 正常操作
Response 通知操作者，并继续运行
Response Measure 没有停机时间

可画成：

Heartbeat 监视器
    -> 服务器无响应
    -> 进程
    -> 正常操作
    -> 通知操作者，并继续运行
    -> 没有停机时间

Modifiability 场景：

Element 内容
Source 开发者
Stimulus 希望修改 UI 界面
Artifact 代码
Environment 设计时
Response 进行修改并完成单元测试
Response Measure 在 3 小时内完成

可画成：

开发者
    -> 希望修改 UI 界面
    -> 代码
    -> 设计时
    -> 进行修改并完成单元测试
    -> 在 3 小时内完成

4. Difference and relationship between architecture pattern and tactic

Tactic 是影响某个质量属性响应控制方式的设计决策。

A tactic is a design decision that influences the control of a quality attribute response.
A collection of tactics is called an architectural strategy.
Tactics are the building blocks of design.

Pattern 更宏观，描述一类上下文中的结构性解决方案；Tactic 更细粒度，通常针对单个质量属性。因此，architecture pattern 可以看作更高层次的结构方案，通常组合多个 tactics 来实现质量属性目标；tactics 可以看作 pattern 内部实现质量属性响应的基本设计手段。

例子 1：Layered pattern

  • 结构思想：把系统分成表示层、业务层、数据层等层次，上层依赖下层。
  • 关联 tactics：
    • Encapsulate：每层隐藏内部实现。
    • Reduce coupling：限制跨层依赖。
    • Increase cohesion：每层承担相对一致的职责。
    • Use an intermediary：通过服务层、接口层隔离变化。

例子 2：Microservices pattern

  • 结构思想：围绕业务能力把系统拆成多个独立服务。
  • 关联 tactics：
    • Decomposition / split module：把大系统拆成较小服务。
    • Encapsulate：每个服务封装自身数据和领域逻辑。
    • Use an intermediary：通过 API Gateway、消息中间件降低直接依赖。
    • Detect / recover faults：用 health check、circuit breaker、service discovery 支持可用性。

5. Software architecture process steps and input / output

Activity 英文 Input Output
识别 ASRs Specifying ASRs Stakeholders, Requirements, Constraints Prioritized Quality Attribute Scenarios
架构设计 Architecture design Prioritized Quality Attribute Scenarios; Requirements, constraints; Patterns and tactics “Sketches” of candidate views, determined by patterns
文档化 Documenting “Sketches” of candidate views, determined by patterns Chosen, combined views, plus documentation beyond views
架构评估 Architecture Evaluation Prioritized Quality Attribute Scenarios; chosen, combined views plus documentation beyond views Evaluation feedback; revised architecture documentation

可以概括为：

  • Specifying ASRs：识别并排序架构驱动因素，特别是质量属性场景。
  • Architecture design：根据 ASRs、需求、约束、patterns and tactics 形成候选架构。
  • Documenting：把候选视图整理成选定的、组合后的架构视图，并补充 view 之外的信息。
  • Architecture Evaluation：用 ASRs 检查架构是否满足关键质量要求，并将反馈返回到 ASR、设计和文档中。

6. Aggregate pattern of Domain-Driven Design

本题暂不展开。

7. Why document architecture using different views? Give name and purpose of 4 example views

需要不同视图的原因：

  • 不同视图支持不同的目标和用户，突出不同的系统元素和关系。
  • 不同视图会以不同维度暴露质量属性问题。
  • 单一视图无法同时清楚表达代码结构、运行时交互、部署映射和质量属性分析。

4 个 example views：

View Purpose
Module Views 说明代码和实现单元如何组织，关注 modules 及 is part of、depends on、is a 等关系
C&C Views 说明系统运行时组件如何交互，关注 components、connectors 及 attachments
Allocation Views 说明软件元素如何映射到环境，关注 software elements 与 environmental elements 的 allocated to 关系
Quality Views 为分析某个质量属性，把 module、C&C、allocation views 中相关元素抽取出来重新组织

如果按 4+1 views 回答：

  • Logical view：表达系统主要功能和对象/模块结构。
  • Process view：表达运行时进程、并发、通信和同步。
  • Development view：表达开发视角下的软件模块组织。
  • Physical view：表达软件到硬件节点和部署环境的映射。
  • Use case scenarios：用场景串联和验证其他视图。

8. Four architectural elements of a microservice system and their roles

这题容易误答成“模式名称”。如果题目问 architectural elements，更稳的答法是写微服务系统中的具体结构元素及其角色。

Architectural element Role
API Gateway 外部 API 客户端进入基于微服务应用的入口点；针对不同客户端提供不同 API；封装应用程序内部结构，减少交互次数
Microservice / Service 围绕业务能力构建的细粒度服务，运行在独立进程中，封装一组专注、内聚的功能职责
Service Registry / Discovery 维护或发现服务实例的位置，使基于 RPI 的客户端能够在网络上发现服务实例
Database per service / Service-owned data store 每个服务拥有自己的数据模型和数据库，避免共享数据库导致服务之间强耦合

如果题目语境强调“事件驱动 / 异步通信”，第 4 个也可以换成：

Architectural element Role
Message Broker / Event Bus 支持服务之间通过事件进行异步通信，降低同步调用链带来的耦合和级联故障风险

不建议把 Circuit Breaker 单独当作 architectural element 的首选答案。Circuit Breaker 更像核心模式 / 可靠性机制，用来避免由于服务故障或网络中断所引起的故障蔓延到其他服务。

9. Basic idea of event-driven architecture style and quality attribute trade-off

事件驱动 / 云原生的核心思想：组织运行时协作。事件负责异步协作，平台负责部署、扩缩容、恢复和观测。

Basic idea：

  • 组件之间不直接同步调用，而是通过事件进行异步协作。
  • 事件表示已经发生的事实，例如 OrderCreated、PaymentCompleted、MaterialReceived。
  • 事件发布者只发布事件，不需要知道所有消费者。
  • 事件消费者订阅事件并执行后续动作。

质量属性权衡：

优先保障 相对牺牲
弹性 可理解性
韧性 可调试性
可扩展性 时序可预测性
可用性 强一致性
自动化运维能力 全局流程清晰性

答题句：

事件驱动架构通过异步事件解耦生产者和消费者，提高系统弹性、可扩展性和可用性；但事件传播、最终一致性和异步时序会降低系统的可理解性、可调试性、时序可预测性和强一致性。

10. Enterprise architecture 4A and relationship

4A 可以按企业架构的四个层次理解：

4A 中文 关注点
Business Architecture 业务架构 企业目标、业务能力、业务流程、组织职责
Application Architecture 应用架构 支撑业务的应用系统、应用边界、应用之间的协作
Data Architecture 数据架构 核心数据对象、数据关系、数据流、数据治理
Technology Architecture 技术架构 基础设施、平台、中间件、网络、部署环境

关系：

  • Business Architecture 是驱动，定义企业要做什么以及业务能力如何组织。
  • Application Architecture 支撑业务架构，把业务能力落实为应用系统和服务。
  • Data Architecture 支撑业务和应用，定义数据如何产生、存储、共享和治理。
  • Technology Architecture 支撑应用和数据，提供运行环境和技术平台。

可以概括为：

Business drives Application;
Application uses and produces Data;
Technology supports Application and Data.

二、分析论述题

1. Seven design decisions, binding time choices and quality attribute effects

七类架构设计决策：

Design decision 中文 解释
Allocation of responsibilities 职责分配 把功能责任和质量属性责任分配给具体软件元素
Coordination model 协调模型 说明运行时元素如何交互，包括通信方向、数据传递和控制传递
Data model 数据模型 说明数据结构、数据关系和生命周期
Management of resources 资源管理 管理 CPU、内存、网络、存储、线程、连接池等资源
Mapping among architecture elements 架构元素映射 说明软件元素到硬件节点、部署环境、实现模块或团队之间的映射关系
Binding time decisions 绑定时机决策 决定元素关系和参数在什么时候确定
Choice of technology 技术选择 选择语言、框架、中间件、数据库、协议和技术栈

Binding time choices：

  • Design time：设计时确定，例如架构风格、模块边界、主要技术栈。
  • Compile time：编译时确定，例如条件编译、静态链接、编译期依赖。
  • Build time：构建时确定，例如构建配置、打包模块、依赖版本。
  • Deployment time：部署时确定，例如部署拓扑、配置文件、数据库地址。
  • Startup / initialization time：启动或初始化时确定，例如加载插件、读取配置。
  • Runtime：运行时确定，例如动态路由、服务发现、策略切换、特性开关。

对质量属性的影响：

Binding time 对可修改性的影响 对可测试性的影响 其他影响
早绑定，如 design / compile time 修改成本高，变化传播范围大，但结构稳定 测试环境更确定，测试更可控 性能较好，运行时复杂度低
中间绑定，如 build / deployment time 可通过配置、部署包、环境变量适配不同环境 可以为不同环境准备不同测试配置 部署治理更重要
晚绑定，如 startup / runtime 可修改性强，可以通过配置、插件、服务发现、运行时参数改变行为 测试组合增多，需要测试更多运行时配置 灵活性提高，但可理解性、可预测性和性能可能下降

答题总结：

绑定越晚，系统通常越灵活、越容易适应变化，因此有利于 modifiability；但晚绑定会增加运行时组合和配置状态，使测试空间变大，可能降低 testability、predictability 和 performance。绑定越早，系统更简单、更可预测、更容易优化，但修改时需要重新设计、重新编译或重新部署。

2. Architecture evolution with course selection system

以大学生选课系统为例说明从 C/S 到三层 / 分层，再到 SOA 的演进。

C/S 的 context 和解决的问题

在早期选课系统中，客户端承担选课界面和部分业务逻辑，服务器管理共享课程数据、学生数据和选课结果。C/S 架构的核心思想是组织交互能力：客户端承担 UI 与部分逻辑，服务器管理共享数据。

C/S 解决的问题：

  • 提升桌面交互体验和易用性。
  • 客户端可以承担部分逻辑，减少服务器压力。
  • 服务器统一管理共享数据，保证基本数据一致性。

质量属性上，C/S 优先保障易用性、响应性和桌面交互体验。

系统庞大复杂后，C/S 的弊端与转向分层

随着选课系统用户规模扩大、业务复杂度增加，C/S 开始出现问题：

  • 客户端安装、升级和版本兼容成本高。
  • 业务逻辑分散在客户端和服务器中，可维护性下降。
  • 客户端与数据访问耦合较重，不利于安全控制和统一治理。
  • 业务功能难以复用，不同客户端或系统可能重复实现相似逻辑。

因此转向三层 / 分层架构。三层 / 分层的核心思想是组织职责边界：表示层、业务层、数据层分离，降低系统内部耦合。

三层 / 分层提升的质量属性：

  • 可维护性：业务逻辑集中在业务层，修改更局部。
  • 可修改性：表示层、业务层、数据层变化可以相对隔离。
  • 安全边界：客户端不直接访问数据层。
  • 部署治理：服务端可以统一部署和管理业务逻辑。

分层解决的问题和后续 limitation

分层解决了单个系统内部职责混杂的问题，使选课系统的展示、业务规则和数据访问分离。但是，当学校后续出现教务系统、缴费系统、成绩系统、学籍系统等多个系统时，分层架构仍有局限：

  • 分层主要整理单个系统内部结构，跨系统复用能力不足。
  • 不同系统之间容易形成点对点接口，集成复杂。
  • 同一业务能力可能在不同系统中重复实现。
  • 跨系统流程变化时，协调成本高。

因此可以进一步演进到 SOA。SOA 的核心思想是组织企业服务能力：通过服务契约暴露可复用能力，支撑跨系统整合。

SOA 对选课系统的价值：

  • 将课程、选课、成绩、缴费、学籍等能力封装成服务。
  • 通过服务契约提高互操作性。
  • 通过服务复用和组合支撑跨系统业务流程。
  • 提高企业级可复用性、可组合性和可治理性。

但 SOA 也会带来简单性和响应性能下降、治理体系较重、ESB 可能成为瓶颈等代价。

三、设计题

题干是实验耗材采购与申请平台。以下答案按你回忆的业务流程组织：申请耗材、审批、采购单签发、供应商接单、物料入库、check。

Task 1. Domain event flow

领域事件命名原则：只写已经发生的事实，用过去时动词；不要写“点击按钮”“提交表单”这类 UI 操作。

库存不足情况下的主流程事件：

  1. Material Requisition Submitted / 领料单已提交
  2. Material Requisition Approved / 领料申请已审核通过
  3. Purchase Order Issued / 采购单已签发
  4. Supplier Accepted Purchase Order / 供应商已接单
  5. Material Delivered / 物料已送达
  6. Material Stocked In / 物料已入库
  7. Inventory Check Completed / 库存检查已完成

事件之间的关系：

这些事件按时间顺序描述一次耗材申请在库存不足时从申请、审批、采购到入库检查的事实流。前一个事件通常为后续 command 或 event 提供触发条件，例如 Requisition Approved 触发采购单签发，Supplier Accepted Purchase Order 触发后续送货与入库。

库存充足情况下的扩展流程：

  • 分叉点：Material Requisition Submitted 之后，系统检查库存。
  • Extend flow：
    1. Inventory Sufficiency Confirmed / 库存充足已确认
    2. Material Reservation Created / 物料预留已创建
    3. Material Requisition Fulfilled / 领料申请已满足

Approver 拒绝情况下的扩展流程：

  • 分叉点：Material Requisition Submitted 之后，审批环节。
  • Extend flow：
    1. Material Requisition Rejected / 领料申请已被拒绝
    2. Applicant Notified / 申请人已被通知

Supplier 拒绝情况下的扩展流程：

  • 分叉点：Purchase Order Issued 之后，供应商接单环节。
  • Extend flow：
    1. Purchase Order Rejected By Supplier / 采购单已被供应商拒绝
    2. Procurement Replanned / 采购计划已重新安排
    3. Alternative Supplier Selected / 备选供应商已选择

Task 2. Event table, policy and hotspot

选择两个领域事件：

Event 触发条件 操作人
Material Requisition Approved Approver 审核领料申请并同意 Approver / 审批人
Purchase Order Issued 库存不足且领料申请已审核通过，需要采购补货 Procurement Officer / 采购员

策略示例：

When Material Requisition Approved occurs,
if the inventory is insufficient,
then Issue Purchase Order command should be triggered.

中文解释：

当领料申请已审核通过事件发生时，如果库存不足，则触发签发采购单命令。

另一个策略：

When Material Stocked In occurs,
then Inventory Check Completed event should be generated after checking the received material.

中文解释：

当物料已入库事件发生后，系统或仓库管理员应检查入库物料，并产生库存检查已完成事件。

Hotspot：

需要专家讨论决策的热点可以选“库存不足的判断规则和采购触发策略”。因为它涉及库存阈值、安全库存、不同耗材优先级、审批权限、预算限制和供应商选择规则，需要业务专家、仓库管理员和采购人员共同确定。

Task 3. Aggregates

可以画出以下聚合：

MaterialRequisition Aggregate
  Aggregate Root: MaterialRequisition
  Entities / Value Objects:
    - RequisitionItem
    - Applicant
    - ApprovalStatus
  Related events:
    - Material Requisition Submitted
    - Material Requisition Approved
    - Material Requisition Rejected

PurchaseOrder Aggregate
  Aggregate Root: PurchaseOrder
  Entities / Value Objects:
    - PurchaseOrderItem
    - Supplier
    - PurchaseOrderStatus
  Related events:
    - Purchase Order Issued
    - Supplier Accepted Purchase Order
    - Purchase Order Rejected By Supplier

Inventory Aggregate
  Aggregate Root: InventoryItem
  Entities / Value Objects:
    - StockQuantity
    - Warehouse
    - StockRecord
  Related events:
    - Material Stocked In
    - Inventory Check Completed
    - Inventory Sufficiency Confirmed

如果只要求至少一个聚合，可以画：

MaterialRequisition
  ├── RequisitionItem
  ├── Applicant
  └── ApprovalStatus

其中 MaterialRequisition 是聚合根。外部对象不能直接修改 RequisitionItem 或 ApprovalStatus，必须通过聚合根维护申请状态和业务规则。与该聚合相关的事件至少包括 Material Requisition Submitted、Material Requisition Approved、Material Requisition Rejected。