Day28-25｜7.2.2 概念与术语
Day28-25｜7.2.2 概念与术语：建立系统架构设计的共同语言
本文对应《系统架构设计师教程（第2版）》第7章“系统架构设计基础知识”7.2.2“概念与术语”。系统架构设计涉及体系结构、架构元素、连接件、配置、视图、模型、模式、风格、框架、参考架构、架构决策和架构描述等概念。术语如果没有统一含义，业务、开发、测试、运维和管理人员就会在同一个词上产生不同理解，最终导致边界、接口、数据和质量目标失控。本篇以软考高级为目标，既讲概念定义，也讲这些概念在架构实践中的关系和使用边界。
一、学习目标与考试定位
完成本节后，应能够解释体系结构、架构元素、连接件、配置、约束、视图、模型、模式和风格等基本术语；能够区分架构风格、架构模式、设计模式、框架和参考架构；理解架构描述、架构决策、架构驱动因素、质量场景和架构风险；能够把术语放入案例和论文，而不是只做名词背诵。
考试常见陷阱是把“架构风格”当成“框架”，把“架构模式”当成“技术产品”，把“视图”当成“系统功能”，把“组件”当成“连接件”，或把“采用微服务”当成完整架构。回答时应先定义，再说明组成、关系、适用场景和工程证据。
二、体系结构与软件架构
体系结构或软件架构通常指系统的高层组织，包括主要元素、元素之间的关系、配置方式和指导设计与演化的原则。它关注系统整体和长期影响，而不是所有实现细节。
架构的范围可以根据问题确定。企业架构关注业务、数据、应用和技术的整体；系统架构关注一个系统及其边界；软件架构关注软件模块、组件、服务、数据和交互；部署架构关注进程、节点、网络和环境。不同范围的架构可以相互映射，但不能混用术语掩盖边界。
架构具有结构性、决策性和演化性。结构性表示元素和关系；决策性表示为什么选择某种分解、通信和数据方案；演化性表示架构要支持变化、修复和技术更新。只画静态模块图而不记录决策和约束，架构描述是不完整的。
三、架构元素
架构元素是构成系统并具有架构意义的主要部分。它可以是模块、组件、服务、进程、数据库、消息队列、缓存、外部系统、节点或数据存储，粒度由架构视图和问题决定。
一个架构元素应至少有名称、职责、边界、输入、输出、拥有者、生命周期和质量约束。元素不是简单的文件集合，而是能够独立讨论、分配、验证或部署的结构单元。
元素可以分为处理元素、数据元素和连接元素。处理元素执行计算和业务逻辑，数据元素保存或提供数据，连接元素支持元素之间通信和协作。例如订单服务是处理元素，订单库是数据元素，消息总线和 API 网关是连接或协调元素。
四、连接件
连接件描述架构元素之间如何交互，包括调用、消息、事件、共享数据、文件、协议、管道、适配器和人工流程。连接件不只是图上的箭头，还包含接口、格式、同步性、方向、超时、重试、顺序、幂等、安全、错误和容量语义。
同步调用具有直接结果和较强一致的优点，但产生时间耦合、级联故障和峰值传递；异步消息可以解耦、削峰和重放，但会带来延迟、重复、乱序、积压和最终一致性。选择连接件时要结合质量场景和业务流程。
共享数据库也可以视为一种连接方式，但它会让多个元素依赖同一数据结构和事务边界。若共享不可避免，应明确读写权限、表或视图边界、所有者和变更流程，不能把共享表当成无成本的集成方式。
五、配置与约束
架构配置是元素和连接件按照特定关系组织成整体的方式。例如分层配置规定表示层、业务层和数据层的依赖；事件驱动配置规定生产者、事件总线和消费者的关系；微服务配置规定服务边界、网关、注册发现和数据服务。
约束限制架构的选择空间。约束可能来自业务法规、既有系统、预算、进度、团队、平台、数据驻留、性能、可用性、安全和供应商合同。架构师应把约束显式记录，并区分硬约束、软约束和可协商假设。
约束并不只是限制，也可以引导设计。例如“敏感数据不能出某区域”引导数据驻留和访问边界，“必须兼容旧接口”引导适配器和版本策略，“RPO 小于五分钟”引导复制和日志保护。忽略约束会使架构在纸面上可行、在现实中不可交付。
六、视图与观点
架构视图是从特定角度对架构进行的表示，服务于一类干系人的关注点。观点或视角规定如何构造、解释和使用某类视图，包括元素、关系、符号、规则和检查方法。
常见视图包括：上下文视图描述系统与外部实体；逻辑视图描述主要职责和业务结构；开发视图描述模块、包、组件和依赖；运行视图描述进程、线程、通信和并发；物理视图描述节点、网络、容器和部署；数据视图描述数据所有权、流转和存储；安全视图描述信任边界、身份、权限、加密和审计。
视图不是架构的不同版本，而是同一架构在不同关注点下的投影。不同视图之间要有一致性规则。例如逻辑视图中的支付服务必须能映射到开发模块、运行进程、数据库、网络和安全边界；若视图之间冲突，应通过架构评审解决。
七、模型与架构描述
模型是对系统某一方面的抽象，可以帮助分析、沟通、推理和验证。E-R 模型表达数据对象和关系，状态模型表达状态变化，部署模型表达节点和连接，依赖模型表达模块关系，容量模型表达负载和资源关系。
架构描述是对架构及其决策、视图、约束、假设、原则和演进信息的系统记录。它可以由图、表、文字、接口契约、数据字典、ADR、质量场景和验证报告组成。图形只是模型的一种表现形式，不能把一张图等同于完整架构描述。
模型要有目的、范围、粒度和版本。没有目的的巨型模型难以维护；没有范围的模型容易把系统边界和外部依赖混在一起；没有版本的模型无法追踪变化。架构文档应写明阅读对象和使用场景。
八、架构风格
架构风格是对系统组织方式的一组约束和特征，描述元素类型、连接方式、配置规则和交互语义。常见风格包括分层、数据流、调用/返回、以数据为中心、虚拟机、独立构件、事件驱动和客户机/服务器等。
风格提供一种可复用的结构思路，但不等于具体系统的完整设计。采用分层风格还要确定层的职责、依赖方向、跨层调用规则和性能影响；采用事件驱动还要设计事件模型、消息语义、幂等、重试和监控。
架构风格的价值是约束选择、提供共同语言和减少设计空间；风险是过度套用。一个系统可以组合多种风格，例如核心业务采用分层，模块之间使用事件，外部接入采用客户机/服务器，数据分析采用管道。组合时要明确边界和冲突。
九、架构模式与设计模式
架构模式是对反复出现的系统级问题提供的可复用结构方案，如 MVC、微服务、发布—订阅、六边形、CQRS 和领域驱动设计中的某些模式。它通常比设计模式粒度更大，涉及多个组件、通信、数据和部署。
设计模式主要解决模块或对象层面的重复设计问题，如工厂、策略、观察者和适配器。设计模式可以支持架构实现，但不能替代架构模式和系统结构。
架构模式不是产品。微服务是一种组织和部署思想，不是某个注册中心、容器或网关；发布—订阅是一种交互模式，不等于某个消息中间件；CQRS 是读写职责分离的模式，不等于必须使用两个数据库。技术实现要服从模式目标和质量场景。
十、框架与参考架构
框架是提供可扩展结构、基础设施和约定的实现骨架，通常包含代码、库、运行时和开发规范。框架可以落实架构模式的一部分，但框架的使用不代表系统自动获得良好的边界、质量和治理。
参考架构是针对某一领域、组织或场景总结的可复用架构蓝图，包含常见元素、关系、原则、接口、质量目标和实现选项。参考架构不是最终架构，必须根据业务、约束、团队和技术环境裁剪。
参考架构和架构模板有助于复用，但要记录适用条件、扩展点、版本、验证证据和维护责任。盲目照搬会把其他项目的假设、复杂度和技术债务带入当前系统。
十一、架构决策、驱动因素与风险
架构决策是对影响系统整体和生命周期的选择进行记录，如服务边界、数据库模型、通信方式、认证方式、部署平台和一致性策略。决策应包含背景、问题、候选、权衡、结果、后果、验证和状态。
架构驱动因素是对结构影响最大的业务目标、质量属性、约束和风险。它们帮助架构师从大量需求中聚焦关键问题。架构风险是决策可能导致目标无法满足的不确定性，如新技术不成熟、分片键不合理、灾备不可恢复和外部接口不稳定。
架构决策、驱动因素和风险之间形成闭环：驱动因素提出决策问题，候选架构响应驱动因素，原型和评审验证决策，风险登记和运行指标反馈新的变化。没有这种闭环，术语再准确也不能形成工程价值。
十二、案例分析：同一个“平台”在不同团队中的含义
某企业建设“统一数据平台”。业务部门认为平台是统一指标和客户画像，开发团队认为平台是数据库和 API，运维团队认为平台是云资源和容器集群，安全团队认为平台是身份、审计和数据隔离。项目启动后，各团队分别建设，最终出现数据口径不一致、接口重复、权限缺失和资源浪费。
问题分析
“平台”是模糊术语，没有明确范围、元素、连接件、视图、目标和责任。不同团队把逻辑架构、数据架构、物理基础设施和安全能力混在一起，缺少参考架构和共同模型。
改进方案
建立术语表和架构观点，分别描述业务能力、数据模型、应用服务、技术部署和安全治理；明确平台的边界和不负责内容，识别数据权威源、指标口径、接口、存储、计算、权限和审计元素；用上下文、逻辑、开发、运行、物理、数据和安全视图统一沟通。记录架构决策、约束、风险和验收指标，按领域分阶段建设，避免以“平台”作为没有边界的万能容器。
十三、综合知识练习与详细答案
练习一
请区分架构风格、架构模式、设计模式和框架。
参考答案：架构风格描述一类系统组织、元素关系和约束的总体特征；架构模式针对反复出现的系统级问题给出可复用结构方案；设计模式主要解决模块或对象层面的设计问题；框架是可以被扩展和配置的实现骨架，提供代码、库和运行约定。框架可以实现模式的一部分，但使用框架不等于完成架构设计。
练习二
“图上的箭头”为什么不能直接视为完整的连接件描述？
参考答案：箭头只表达方向或关系，连接件还应说明同步/异步、协议、数据格式、超时、重试、顺序、幂等、安全、容量、错误和一致性语义。缺少这些内容，无法评估性能、可靠性、安全和故障传播，也无法指导实现和测试。
练习三
一个逻辑视图显示服务自治，但数据视图显示所有服务直接写同一数据库，应如何处理？
参考答案：视图之间存在架构矛盾。应确认数据所有权、事务和变更需求，若服务确需自治，则拆分数据或通过服务接口、事件和读模型协同；若暂时共享，明确逻辑视图、读写权限、所有者和变更控制，并记录这是过渡方案和风险。更新相关视图、决策、测试和演进路线，不能忽略不一致。
十四、论文写作素材
论文中可以这样使用术语：我将系统架构定义为主要元素、连接件、配置、约束和指导原则的集合，先建立系统上下文和架构驱动因素，再通过逻辑、开发、运行、物理、数据和安全视图描述结构。元素明确职责和边界，连接件明确接口、同步性、数据、超时、幂等和错误语义，配置体现模块、服务、数据和部署关系。
在方案设计中，我区分架构风格、架构模式、设计模式和具体框架，选择分层、事件驱动、服务化或数据中心等风格时说明适用条件和质量目标；使用适配器、发布—订阅、CQRS 或其他模式解决具体问题，但不把技术产品名称当成架构结论。架构决策记录候选方案、权衡、后果、验证和残余风险。
参考架构和公共框架只作为复用起点，结合当前业务、约束、团队和数据进行裁剪；通过质量场景、原型、容量压测、故障注入、安全评审和恢复演练验证。术语表、模型、视图、决策、接口契约和验证报告纳入配置管理，保证不同团队使用同一语言，并支持后续治理和演进。
十五、今日复盘
架构术语的核心是建立边界和关系：架构由元素、连接件、配置和约束组成；视图从不同关注点表达同一架构，模型提供抽象和分析；风格描述总体组织特征，模式提供可复用结构方案，设计模式解决局部设计，框架负责实现骨架，参考架构提供可裁剪蓝图；决策、驱动因素和风险把术语连接到工程行动。
记忆主线：
元素是什么、连接如何协作、配置怎样组织、约束为何存在；视图服务干系人，模式服务问题，框架服务实现，决策必须有权衡和证据。
下一篇进入 7.2.3 基于体系结构的开发模型，学习架构驱动开发模型、迭代过程、架构基线和风险控制。
