临近软件架构设计师考试，软件架构设计作为考试的核心模块（占比40%-50%），贯穿上午场信息系统综合知识（20-25分）、下午场案例分析（30-40分）及论文写作（必考核心方向），是“拉开分差、顺利通关”的关键。本总结严格遵循最新考试大纲，全面覆盖软件架构设计的所有考点，兼顾全面性、针对性和实用性，重点区分“必考考点”“高频考点”“低频考点”，补充真题关联、易错点辨析、记忆技巧和实操方法，总字数超1万字，排版层次清晰、重点突出，无需考生额外筛选内容，直接用于考前背诵、查漏补缺、真题适配即可。

核心说明：软件架构设计师考试中，架构设计的命题有3个显著特点：① 侧重“理论+实操”，既考查架构基础概念、设计原则，也考查架构模式选型、架构评估、架构演化等实操内容；② 结合行业场景，常以分布式系统、微服务、云原生、大数据等主流场景为背景命题；③ 论文写作高频聚焦“架构设计方案”“架构评估方法”“架构演化策略”，需结合考点灵活运用。本总结将针对这些特点，强化核心考点、补充实操细节，助力考生快速掌握得分要点，规避易错点。

第一部分 软件架构设计基础（必考，每年3-4题）

软件架构设计基础是整个架构模块的基石，核心考查架构的定义、核心要素、架构师角色与职责、架构设计流程等基础内容，命题形式以单选题为主，难度中等偏易，重点记忆核心定义和辨析点，避免混淆，为后续核心模块学习奠定基础。

1.1 软件架构的定义与核心内涵（必背）

1.1.1 软件架构的权威定义（必考，单选/判断）

根据《软件架构实践》及软件架构设计师考试大纲，软件架构的核心定义的是：软件架构是系统的一个或多个结构，包括软件组件、组件之间的连接关系、组件与环境之间的连接关系，以及指导这些结构设计和演化的原则与约束。

补充说明：考试中常考查“架构的核心构成”，需牢记3个核心要素：组件（Component）、连接件（Connector）、约束（Constraint），这是区分“架构”与“普通设计”的关键，也是后续架构模式、架构设计的基础。

核心关键词（必背）：结构、组件、连接件、约束、演化原则，避免与“软件设计”“模块划分”混淆——软件设计侧重“具体实现细节”，而软件架构侧重“整体结构与全局决策”，是“高层设计”，指导底层设计的开展。

1.1.2 软件架构的核心作用（高频考点，多选题）

软件架构的作用贯穿软件全生命周期，是架构设计的核心价值体现，考试中常以多选题形式考查，需精准记忆，结合场景理解：

• 明确系统整体结构：划分系统组件、定义组件间的交互关系，明确系统的层次、模块边界，避免组件耦合混乱，为后续开发、测试、部署提供统一的框架指导。例如：分布式系统的架构设计，明确数据层、业务层、接口层的划分，确保各层职责清晰。

• 指导开发与协作：架构设计确定技术选型、开发规范，明确各团队（开发、测试、设计）的工作边界和协作方式，提升开发效率，避免重复开发和需求偏差。例如：微服务架构设计，明确每个微服务的职责、接口规范，指导各开发团队并行开发。

• 控制系统复杂性：通过分层、模块化、抽象等架构设计手段，将复杂系统拆解为可管理、可维护的组件，降低系统的理解难度和维护成本。例如：大型电商系统，通过架构设计拆解为商品、订单、支付、用户等核心模块，每个模块独立维护，降低整体复杂性。

• 保障系统质量属性：架构设计直接决定系统的质量属性（如性能、可靠性、可用性、安全性、可扩展性），通过合理的架构选型和设计策略，满足系统的质量要求。例如：高并发系统采用分布式架构、缓存架构，保障系统的性能和可用性。

• 支持系统演化与扩展：良好的架构设计具备可扩展性，能够适应需求的变化和业务的增长，无需大规模重构系统，降低系统演化的成本和风险。例如：微服务架构支持按需扩展单个服务，无需修改整个系统架构。

• 便于项目管理与风险管控：架构设计明确项目的技术路线、核心难点和风险点，为项目进度规划、资源分配、风险管控提供依据。例如：架构设计中识别到技术选型风险，可提前制定备选方案，避免项目延期。

1.1.3 软件架构与软件设计的区别与联系（必考，辨析题）

考试中常以单选题、多选题形式考查两者的区别，核心是区分“高层设计”与“底层设计”，具体对比如下（必背，易混淆点）：

对比维度	软件架构（高层设计）	软件设计（底层设计）
设计层面	全局层面、宏观层面，关注系统整体结构	局部层面、微观层面，关注具体实现细节
核心关注	组件划分、连接件设计、约束定义、质量属性保障	模块实现、接口细节、算法设计、数据结构设计
作用范围	贯穿软件全生命周期，指导底层设计和项目管理	主要作用于开发阶段，服务于具体功能实现
变更影响	变更成本高、影响范围广，可能导致系统重构	变更成本低、影响范围小，仅影响单个模块或功能
示例	选择微服务架构、分层架构，定义服务间接口规范	设计单个微服务的接口实现、编写具体代码、设计数据库表结构
联系	软件架构是软件设计的基础和指导，软件设计是软件架构的落地和实现；两者相辅相成，架构设计确定“做什么”，软件设计确定“怎么做”，缺一不可。

1.1.4 软件架构的核心要素（必背，每年1题）

软件架构的核心要素包括4个部分，是架构设计、架构评估的基础，考试中常以单选题形式考查“要素的判断”或“要素的作用”，需牢记每个要素的核心含义：

1. 组件（Component）：

   1. 定义：系统中具有独立功能、可替换、可复用的模块单元，是架构的基本组成部分。组件可以是一个模块、一个服务、一个类库，甚至是一个独立的系统。

   2. 核心特点：独立性（可独立开发、测试、部署）、可替换性（同类组件可相互替换）、可复用性（可在不同项目或系统中复用）。

   3. 示例：电商系统中的“商品组件”“订单组件”“支付组件”，每个组件独立负责对应功能，可独立部署和扩展。

2. 连接件（Connector）：

   1. 定义：用于连接不同组件，实现组件间通信、数据交互、协作的桥梁，明确组件间的交互方式和协议。

   2. 常见类型：接口调用、消息队列、远程过程调用（RPC）、数据库共享、事件驱动等。

   3. 示例：微服务架构中，服务间通过RESTful接口、Dubbo RPC进行通信，这些接口和RPC协议就是连接件；分布式系统中，消息队列（如RabbitMQ）也是典型的连接件，实现组件间的异步通信。

3. 约束（Constraint）：

   1. 定义：架构设计过程中必须遵循的规则、限制和要求，用于规范组件的设计、连接件的实现，保障系统的一致性和质量。

   2. 常见类型：技术约束（如必须采用Java语言、SpringBoot框架）、性能约束（如并发量≥10万QPS）、安全约束（如数据加密传输）、接口约束（如统一采用RESTful规范）。

   3. 示例：某项目约束“所有微服务必须采用SpringCloud框架”“数据库必须使用MySQL 8.0及以上版本”，这些都是架构约束。

4. 架构视图（View）：

   1. 定义：从不同角度对软件架构的描述，用于满足不同相关方（架构师、开发人员、测试人员、管理层）的需求，便于各方理解架构。

   2. 常见视图：逻辑视图（描述组件功能和交互）、物理视图（描述组件部署和硬件分布）、进程视图（描述组件运行时的进程和线程）、部署视图（描述组件与硬件的映射关系）、数据视图（描述数据存储和流转）。

   3. 补充：考试中常考查“4+1视图模型”（后续详细讲解），这是架构视图的核心考点。

1.1.5 真题关联

【2023年上半年单选】以下关于软件架构的描述，正确的是（ ）

A. 软件架构是软件设计的具体实现细节，关注模块的代码编写

B. 软件架构的核心要素包括组件、连接件、约束和架构视图

C. 软件架构变更成本低，仅影响单个模块的实现

D. 软件架构不涉及技术选型，仅关注系统的功能划分

解析：答案为B。A错误，软件架构是高层设计，不关注具体实现细节；C错误，架构变更成本高、影响范围广；D错误，架构设计包含技术选型；B正确，符合软件架构的核心要素定义，故选B。

1.2 软件架构师的角色与职责（高频考点，单选/案例题）

软件架构师是架构设计的核心执行者，其角色与职责是考试的高频考点，常以单选题形式考查“职责判断”，或在案例分析题中考查“架构师的工作内容”，需结合架构设计全流程，牢记核心职责。

1.2.1 软件架构师的核心角色

软件架构师在项目中扮演4个核心角色，贯穿项目全生命周期，需理解每个角色的核心定位：

• 架构决策者：负责制定系统的整体架构方案、技术选型、组件划分、接口规范等核心决策，确保架构方案符合项目目标和质量要求。

• 技术领导者：引领项目的技术方向，指导开发团队开展底层设计和编码工作，解决开发过程中的技术难题，确保技术方案的落地执行。

• 需求转化者：将客户的业务需求、用户需求转化为可落地的架构设计方案，确保架构能够满足业务需求，同时兼顾技术可行性和系统质量。

• 风险管控者：识别架构设计中的技术风险、质量风险，制定风险应对措施，监控架构落地过程中的风险，避免风险扩大导致项目失败。

1.2.2 软件架构师的核心职责（必背，案例题高频）

软件架构师的职责覆盖架构设计全流程，结合考试大纲和命题特点，重点掌握以下10项核心职责，案例分析题中常考查“架构师的工作内容是否合理”“缺失的职责”：

1. 参与需求分析，梳理核心业务需求和非功能需求（质量属性需求），将需求转化为架构设计的约束和目标。

2. 制定系统的整体架构方案，包括架构模式选型（如分层、微服务、分布式）、组件划分、连接件设计、接口规范定义。

3. 进行技术选型，包括编程语言、框架、数据库、中间件（如缓存、消息队列）、部署环境等，确保技术选型的合理性和可行性。

4. 编写架构设计文档，包括架构视图、组件描述、接口规范、技术选型说明、约束条件等，为开发、测试、部署提供指导。

5. 组织架构评审，邀请技术专家、项目相关方对架构设计方案进行评审，收集反馈意见，优化架构方案。

6. 指导开发团队开展底层设计和编码工作，确保开发工作符合架构设计要求，避免偏离架构方向。

7. 监控架构落地过程，解决架构实施过程中的技术难题，处理需求变更带来的架构调整，确保架构的稳定性和可扩展性。

8. 进行架构评估，定期对系统架构的质量属性（性能、可靠性、可用性等）进行评估，识别架构缺陷，提出优化方案。

9. 负责系统架构的演化和升级，根据业务发展和技术进步，制定架构演化策略，确保架构能够适应业务变化。

10. 参与项目管理，协调技术资源，制定技术路线图，把控技术进度，配合项目经理完成项目交付。

1.2.3 软件架构师与其他角色的区别（易错点辨析）

考试中常考查架构师与项目经理、开发工程师、测试工程师的职责区别，避免混淆，具体辨析如下：

• 架构师 vs 项目经理：架构师侧重“技术决策和架构设计”，关注“怎么做才合理”；项目经理侧重“项目进度、成本、资源管理”，关注“按时按质按预算交付”，两者协同工作，架构师提供技术支持，项目经理协调资源。

• 架构师 vs 开发工程师：架构师侧重“高层设计和全局决策”，指导开发工作；开发工程师侧重“底层实现和代码编写”，落实架构设计要求，架构师不负责具体编码，但需审核代码是否符合架构规范。

• 架构师 vs 测试工程师：架构师侧重“设计阶段的质量保障”，通过架构设计规避质量风险；测试工程师侧重“测试阶段的质量验证”，验证架构设计的落地效果和系统质量，架构师需配合测试工程师制定测试策略。

1.2.4 真题关联

【2022年下半年案例分析题节选】某大型分布式电商平台项目中，架构师仅负责制定了架构设计方案和技术选型，未参与需求分析和架构评审，也未指导开发团队的底层设计工作，导致开发过程中出现组件耦合混乱、接口不兼容等问题，项目进度严重延期。请分析该架构师在工作中缺失了哪些核心职责？

解析：缺失的核心职责包括：① 参与需求分析，将业务需求转化为架构设计目标的职责；② 组织架构评审，收集反馈优化架构方案的职责；③ 指导开发团队开展底层设计，确保开发符合架构要求的职责；④ 监控架构落地过程，解决技术难题的职责。

1.3 软件架构设计的流程与原则（必背，每年2题）

软件架构设计的流程和原则是架构设计的核心逻辑，考试中常以单选题形式考查“流程顺序”“原则判断”，或在案例分析题中考查“架构设计流程是否合理”“是否遵循设计原则”，需牢记流程步骤和核心原则，结合场景理解应用。

1.3.1 软件架构设计的完整流程（必背，流程顺序高频）

软件架构设计贯穿项目规划阶段和执行阶段，遵循“需求分析→架构选型→架构设计→架构评审→架构落地→架构评估→架构演化”的完整流程，每个阶段有明确的任务和产出物，需牢记每个阶段的核心内容：

1. 阶段1：需求分析（架构设计的前提）

   1. 核心任务：梳理业务需求（功能需求）和非功能需求（质量属性需求），明确需求的优先级，识别需求中的约束条件，形成需求规格说明书。

   2. 重点关注：非功能需求（性能、可靠性、可用性、安全性、可扩展性等），这是架构选型和设计的核心依据——例如，高并发需求对应分布式架构，高可用需求对应集群部署。

   3. 产出物：需求规格说明书、需求优先级清单、非功能需求明细。

2. 阶段2：架构选型（架构设计的核心步骤）

   1. 核心任务：根据需求分析结果，选择合适的架构模式（如分层架构、微服务架构、分布式架构），确定架构的整体风格和核心框架，明确技术选型方向。

   2. 选型依据：需求特点（功能复杂度、并发量）、技术成熟度、团队技术能力、项目成本、可扩展性要求等。

   3. 产出物：架构选型报告、技术选型清单。

3. 阶段3：架构设计（具体设计阶段）

   1. 核心任务：基于架构选型结果，进行组件划分、连接件设计、接口规范定义，绘制架构视图（如逻辑视图、物理视图），明确组件间的交互关系和约束条件。

   2. 重点工作：组件划分需遵循“高内聚、低耦合”原则；接口设计需规范、统一，便于组件间交互和后续扩展。

   3. 产出物：架构设计文档、架构视图图表、接口规范文档。

4. 阶段4：架构评审（质量把控阶段）

   1. 核心任务：组织技术专家、项目相关方（客户、项目经理、开发团队）对架构设计方案进行评审，检查架构是否满足需求、技术选型是否合理、组件划分是否清晰、是否存在技术风险等。

   2. 评审重点：架构的可行性、合理性、可扩展性、质量属性保障能力、风险点。

   3. 产出物：架构评审报告、架构优化方案。

5. 阶段5：架构落地（执行阶段）

   1. 核心任务：指导开发团队开展底层设计和编码工作，将架构设计方案落地为实际的软件系统，监控架构落地过程，解决实施过程中的技术难题，处理需求变更带来的架构调整。

   2. 重点工作：确保开发工作符合架构规范，避免偏离架构方向；协调组件间的集成，确保组件交互正常。

   3. 产出物：可执行的软件系统、架构落地报告、变更记录。

6. 阶段6：架构评估（优化阶段）

   1. 核心任务：系统上线后，定期对架构的质量属性（性能、可靠性、可用性等）进行评估，识别架构缺陷和性能瓶颈，提出优化方案。

   2. 评估方法：性能测试、压力测试、故障注入测试、代码评审等。

   3. 产出物：架构评估报告、架构优化方案。

7. 阶段7：架构演化（持续优化阶段）

   1. 核心任务：根据业务发展、需求变更、技术进步，对架构进行持续优化和升级，确保架构能够适应新的业务需求和技术环境，延长系统的生命周期。

   2. 演化策略：增量式演化（逐步优化组件和接口）、重构式演化（大规模调整架构）、替换式演化（替换核心组件或架构模式）。

   3. 产出物：架构演化方案、演化实施报告。

记忆技巧：按“需求→选型→设计→评审→落地→评估→演化”的顺序记忆，核心是“需求是前提，选型是核心，评审是保障，落地是执行，演化是持续优化”，结合每个阶段的产出物辅助记忆，避免遗漏。

1.3.2 软件架构设计的核心原则（必背，每年1题，案例题高频）

软件架构设计的核心原则是架构设计的底层逻辑，贯穿架构设计的全过程，考试中常以单选题形式考查“原则的判断”，或在案例分析题中考查“架构设计是否遵循原则”，需牢记每个原则的核心含义和应用场景：

1. 高内聚、低耦合原则（最核心原则，必考）

   1. 核心含义：高内聚（组件内部的功能高度相关，组件内部的职责清晰、单一，组件内部的代码复用性高）；低耦合（组件之间的依赖关系尽可能少，组件之间的交互尽可能简单，一个组件的变更对其他组件的影响尽可能小）。

   2. 应用场景：组件划分、接口设计、模块拆分，是架构设计的核心准则。例如：将电商系统拆分为商品、订单、支付等组件，每个组件负责单一功能（高内聚），组件间通过标准化接口交互（低耦合）。

   3. 易错点：避免“高耦合、低内聚”——例如，将商品管理、订单管理、支付管理放在一个组件中，属于低内聚；组件间直接调用内部方法，而非通过接口交互，属于高耦合。

2. 单一职责原则

   1. 核心含义：每个组件、每个模块、每个接口只负责一个核心职责，避免一个组件承担多个不相关的功能，确保组件的职责清晰、可维护、可复用。

   2. 应用场景：组件划分、接口设计。例如：商品组件只负责商品的增删改查、库存管理，不负责订单处理；订单组件只负责订单的创建、支付、取消，不负责商品库存更新。

   3. 与高内聚的关系：单一职责是高内聚的具体体现，高内聚的组件必然遵循单一职责原则。

3. 开闭原则

   1. 核心含义：架构设计应允许对系统进行扩展（新增功能、优化性能），但不允许修改系统的核心代码和现有组件，即“对扩展开放，对修改关闭”。

   2. 应用场景：架构的可扩展性设计、组件的接口设计。例如：通过接口抽象、插件化设计，新增功能时只需新增组件实现接口，无需修改现有组件代码。

   3. 示例：微服务架构中，新增一个“优惠券服务”，只需新增该服务并通过标准化接口与其他服务交互，无需修改商品、订单等现有服务的代码。

4. 接口隔离原则

   1. 核心含义：将组件的接口拆分为多个专用接口，每个接口只提供特定的功能，避免一个接口包含过多不相关的方法，确保接口的简洁性和针对性，减少组件间的依赖。

   2. 应用场景：接口设计。例如：商品组件的接口拆分为“商品查询接口”“商品新增接口”“库存更新接口”，而非一个接口包含所有商品相关的方法，避免其他组件依赖不需要的接口方法。

5. 依赖倒置原则

   1. 核心含义：依赖于抽象，而非依赖于具体实现；高层模块不依赖于底层模块，两者都依赖于抽象接口。这样可以降低模块间的耦合，提高系统的可扩展性和可维护性。

   2. 应用场景：技术选型、组件设计。例如：架构设计中，定义“数据存储接口”，底层可以实现MySQL、Redis、MongoDB等多种存储方式，高层模块只需依赖“数据存储接口”，无需依赖具体的存储实现，便于后续替换存储方式。

6. 最小知识原则（迪米特法则）

   1. 核心含义：一个组件只应了解与其直接交互的组件，不应了解其他组件的内部细节，减少组件间的信息交互，降低耦合度。

   2. 应用场景：组件交互设计。例如：商品组件与订单组件交互时，只需调用订单组件的公开接口，无需了解订单组件内部的业务逻辑和数据处理流程。

7. 模块化原则

   1. 核心含义：将系统拆分为多个独立的模块（组件），每个模块负责一个特定的功能，模块之间通过标准化接口交互，便于模块的开发、测试、维护和复用。

   2. 应用场景：系统拆分、组件设计。例如：将大型系统拆分为前端模块、后端模块、数据模块、缓存模块，每个模块独立开发和部署。

8. 可扩展性原则

   1. 核心含义：架构设计应具备良好的可扩展性，能够适应业务需求的变化和业务规模的增长，无需大规模重构系统，降低系统演化的成本。

   2. 应用场景：架构选型、组件设计。例如：微服务架构、分布式架构具备良好的可扩展性，可按需新增服务、扩展节点；分层架构通过新增层或扩展层的功能，实现系统扩展。

9. 可维护性原则

   1. 核心含义：架构设计应便于系统的维护和故障排查，组件的职责清晰、接口规范、代码可理解，降低维护成本。

   2. 应用场景：组件划分、文档编写。例如：组件命名规范、接口文档完整、代码注释清晰，便于维护人员理解系统架构和代码逻辑。

10. 质量属性优先原则

    1. 核心含义：架构设计应优先保障系统的核心质量属性（如性能、可靠性、可用性），在满足质量属性的前提下，再考虑功能实现和开发效率，避免“重功能、轻质量”。

    2. 应用场景：架构选型、技术选型。例如：高并发系统优先选择分布式架构、缓存架构，保障系统性能；金融系统优先选择高可靠、高安全的架构，保障数据安全和系统稳定。

记忆技巧：核心原则可总结为“高内低耦、单一职责、开闭隔离、依赖抽象、最小知识、模块可扩可维护、质量优先”，结合应用场景记忆，避免死记硬背，重点理解“高内聚、低耦合”“开闭原则”“可扩展性原则”，这三个是考试的高频考点。

1.3.3 真题关联

【2023年下半年单选】以下关于软件架构设计原则的描述，错误的是（ ）

A. 高内聚、低耦合原则要求组件内部功能高度相关，组件之间依赖尽可能少

B. 开闭原则要求对扩展开放、对修改关闭，允许新增功能但不允许修改核心代码

C. 单一职责原则要求一个组件可以承担多个相关的功能，提高组件的复用性

D. 依赖倒置原则要求依赖于抽象，而非依赖于具体实现

解析：答案为C。C错误，单一职责原则要求每个组件只负责一个核心职责，不允许承担多个不相关的功能；A、B、D均正确，符合架构设计原则的定义，故选C。

1.4 软件架构视图与视图模型（必考，每年1-2题）

软件架构视图是架构设计的重要组成部分，用于从不同角度描述架构，满足不同相关方的需求，考试中重点考查“4+1视图模型”，同时考查常见架构视图的含义和应用，命题形式以单选题、多选题为主。

1.4.1 常见的软件架构视图（高频考点）

软件架构视图从不同维度描述系统架构，常见的视图有5种，需牢记每种视图的核心描述角度和适用场景：

1. 逻辑视图（Logical View）

   1. 核心描述：从功能角度描述系统的组件、组件间的交互关系，以及组件的功能职责，不关注组件的具体实现和部署位置。

   2. 适用场景：供架构师、开发人员理解系统的功能结构和组件划分，指导底层设计和编码工作。

   3. 示例：电商系统的逻辑视图，展示商品组件、订单组件、支付组件的功能及组件间的接口交互关系。

2. 物理视图（Physical View）

   1. 核心描述：从硬件部署角度描述系统的组件与硬件设备的映射关系，展示组件的部署位置、硬件设备的配置、网络拓扑结构。

   2. 适用场景：供运维人员、部署人员理解系统的部署架构，指导系统部署和运维工作。

   3. 示例：分布式系统的物理视图，展示微服务组件部署在哪些服务器上、服务器的配置、网络连接方式。

3. 进程视图（Process View）

   1. 核心描述：从运行时角度描述系统的进程、线程结构，展示组件运行时的进程分布、线程交互、资源占用情况。

   2. 适用场景：供架构师、开发人员分析系统的运行时性能、并发处理能力，排查运行时故障。

   3. 示例：高并发系统的进程视图，展示每个组件对应的进程、线程数量，以及线程间的通信方式。

4. 部署视图（Deployment View）

   1. 核心描述：与物理视图类似，侧重描述组件的部署策略、部署顺序、部署依赖关系，以及部署环境的配置（如操作系统、中间件版本）。

   2. 适用场景：供项目经理、运维人员制定部署计划，指导系统部署和环境配置。

   3. 示例：微服务系统的部署视图，展示每个微服务的部署顺序（先部署基础服务，再部署业务服务）、部署依赖（如支付服务依赖用户服务）。

5. 数据视图（Data View）

   1. 核心描述：从数据角度描述系统的数据存储、数据流转、数据格式、数据交互方式，展示数据在组件间的传递过程。

   2. 适用场景：供架构师、开发人员、数据库工程师理解系统的数据结构和数据流向，指导数据库设计和数据交互开发。

   3. 示例：电商系统的数据视图，展示商品数据、订单数据、用户数据的存储位置（数据库、缓存），以及数据在组件间的流转（如订单创建时，用户数据从用户组件传递到订单组件）。

1.4.2 4+1视图模型（必背，每年1题）

4+1视图模型是软件架构设计的经典视图模型，由Philippe Kruchten提出，是考试的核心考点，需牢记4个核心视图和1个场景视图的含义、作用，以及各视图之间的关系：

1. 4个核心视图（基础视图）

   1. 逻辑视图：描述系统的功能结构，回答“系统能做什么”，对应上述的逻辑视图，核心是组件和组件间的功能交互。

   2. 物理视图：描述系统的硬件部署，回答“系统部署在什么地方”，对应上述的物理视图，核心是组件与硬件的映射关系。

   3. 进程视图：描述系统的运行时结构，回答“系统如何运行”，对应上述的进程视图，核心是进程、线程和运行时交互。

   4. 开发视图（Development View）：描述系统的开发结构，回答“系统如何开发”，展示系统的模块划分、代码组织、开发规范，供开发团队使用，确保开发工作的一致性。

2. 1个场景视图（核心驱动视图）

   1. 场景视图（Scenarios）：也称为用例视图，通过具体的用例场景，描述系统的功能实现和组件交互，是其他4个视图的驱动因素——其他4个视图都是为了满足场景视图中的用例需求而设计的。

   2. 作用：将用户需求转化为具体的架构设计场景，验证架构设计是否满足需求，同时便于相关方理解架构的实际应用。

3. 各视图之间的关系

   1. 场景视图是驱动，其他4个视图围绕场景视图展开，确保架构能够满足用户需求。

   2. 逻辑视图和开发视图关注“软件本身”，物理视图和进程视图关注“软件的运行环境”。

   3. 各视图相互补充，共同构成完整的软件架构描述，满足不同相关方的需求（开发人员关注开发视图，运维人员关注物理视图，架构师关注所有视图）。

记忆技巧：4个核心视图记“逻辑、物理、进程、开发”，1个场景视图记“用例驱动”，核心关系是“场景驱动其他视图，各视图相互补充”，避免混淆开发视图和其他视图——开发视图侧重“开发组织”，逻辑视图侧重“功能结构”。

1.4.3 真题关联

【2022年上半年单选】在4+1视图模型中，用于描述系统的硬件部署、组件与硬件映射关系的视图是（ ）

A. 逻辑视图 B. 物理视图 C. 开发视图 D. 进程视图

解析：答案为B。物理视图的核心是描述系统的硬件部署和组件与硬件的映射关系；A描述功能结构；C描述开发组织；D描述运行时进程结构，故选B。

1.5 软件架构设计的文档规范（低频考点，了解即可）

软件架构设计文档是架构设计的重要产出物，用于记录架构设计方案、指导开发和运维工作，考试中偶尔考查文档的组成部分，需了解核心文档的内容：

1.5.1 核心架构设计文档

• 架构设计说明书：核心文档，包含架构概述、需求分析、架构选型、组件划分、连接件设计、接口规范、约束条件、架构视图、技术选型说明等内容，是架构设计的核心成果。

• 架构评审报告：记录架构评审的过程、评审意见、优化方案，用于跟踪架构优化情况。

• 接口规范文档：详细描述组件间的接口定义、接口参数、接口返回值、接口调用协议等，指导开发人员进行接口开发和集成。

• 技术选型报告：记录技术选型的依据、选型结果、备选方案、技术风险等，确保技术选型的合理性。

• 架构演化报告：记录架构演化的原因、演化策略、演化实施过程、演化效果，用于跟踪架构的持续优化。

1.5.2 文档编写原则

• 清晰性：文档内容清晰、明确，避免模糊不清的表述，便于相关方理解。

• 完整性：文档内容完整，覆盖架构设计的所有核心内容，不遗漏关键信息。

• 一致性：文档中的术语、接口定义、架构描述保持一致，避免矛盾。

• 可维护性：文档便于更新和维护，能够及时反映架构的变更和优化。

第二部分 软件架构模式（必考，每年4-5题，案例题核心）

软件架构模式是架构设计的核心内容，是经过实践验证的、可复用的架构设计方案，考试中重点考查常见架构模式的特点、适用场景、优缺点，以及模式之间的区别，命题形式包括单选题、多选题、案例分析题（架构模式选型），是拉开分差的关键模块。

核心说明：考试中高频考查的架构模式包括：分层架构、微服务架构、分布式架构、集群架构、缓存架构、消息队列架构、事件驱动架构、管道-过滤器架构、面向服务架构（SOA），需重点掌握这些模式的核心内容，结合场景理解选型依据。

2.1 基础架构模式（必背，每年2题）

基础架构模式是最常用、最基础的架构模式，包括分层架构、管道-过滤器架构、黑板架构，重点考查分层架构，其他两种模式了解核心特点即可。

2.1.1 分层架构（Layered Architecture）（必考，案例题高频）

分层架构是最经典、最常用的架构模式，几乎所有软件系统都会采用分层架构的思想，考试中常考查分层的划分、各层的职责、优缺点、适用场景，需重点掌握。

（1）核心定义

分层架构将系统按照功能和职责，自上而下划分为多个独立的层次，每个层次只负责特定的功能，层次之间通过标准化接口交互，上层依赖下层，下层不依赖上层，即“上层调用下层，下层不调用上层”。

（2）常见分层（必背，核心考点）

软件系统中最常见的是4层架构，部分复杂系统会扩展为5层，需牢记各层的职责、核心功能和典型技术，考试中常考查“层的职责判断”“层的顺序”：

1. 表现层（Presentation Layer）

   1. 核心职责：负责与用户交互，展示数据和接收用户输入，将用户请求传递给业务逻辑层，将业务逻辑层返回的结果展示给用户。

   2. 典型技术：前端框架（Vue、React、Angular）、HTML、CSS、JavaScript、移动端框架（Flutter、React Native）。

   3. 示例：电商系统的前端页面（商品列表页、订单提交页），负责展示商品信息、接收用户的下单请求。

2. 业务逻辑层（Business Logic Layer）

   1. 核心职责：负责处理核心业务逻辑，接收表现层的请求，进行业务规则验证、业务流程处理，调用数据访问层获取或存储数据，将处理结果返回给表现层。

   2. 典型技术：后端框架（Spring、SpringBoot、SpringMVC）、业务逻辑组件、规则引擎。

   3. 示例：电商系统的订单处理逻辑（订单创建、支付验证、库存扣减）、商品管理逻辑（商品新增、修改、查询）。

3. 数据访问层（Data Access Layer，DAL）

   1. 核心职责：负责与数据存储层交互，提供数据的增删改查操作，封装数据访问细节，为业务逻辑层提供数据支持，屏蔽数据存储的具体实现（如数据库类型）。

   2. 典型技术：持久层框架（MyBatis、Hibernate）、JDBC、数据访问组件。

   3. 示例：电商系统中，商品数据的查询、订单数据的插入、库存数据的更新，均由数据访问层实现。

4. 数据存储层（Data Storage Layer）

   1. 核心职责：负责数据的持久化存储，提供数据的存储和读取能力，不参与业务逻辑处理。

   2. 典型技术：数据库（MySQL、Oracle、SQL Server）、缓存（Redis、Memcached）、文件存储（MinIO、OSS）。