概述

无论架构是明确形成还是隐性形成，如果没有被记录下来，其作用都是有限的。只有经过适当记录的架构才能持续地被交流、讨论和进一步发展。

软件架构不仅要与其他架构师讨论。软件架构的所有方面都要向不同利益代表（利益相关者）展示、与他们讨论，并共同进一步发展。例如，客户和用户也可以参与影响他们的架构决策。开发人员也应该参与讨论，特别是对于与最终实现相关的架构方面的交流和讨论。

根据 IEEE 标准 42010:2011，即《软件密集型系统架构描述的推荐实践》[IEEE 42010:2011]，软件架构描述包含一系列用于描绘软件架构的工件。相应的标准定义了架构描述的概念模型。下图展示了概念模型中我们特别感兴趣的部分。

在模型的这段摘录中，一个系统受其环境的影响，反之亦然。每个系统都有一个架构。根据 IEEE 标准，这个架构由一个单一的架构描述来描述。乍一看，这似乎是一种限制。然而，如上所述，该标准将架构描述定义为由一系列工件组成。这意味着一个架构是由一系列描述来记录的。这一点在标准中本可以（也应该）表述得更清楚。

一个系统也有许多利益相关者，而利益相关者又有许多关注点。架构描述解决了利益相关者的关注点，并在相关的基本原理中用它们来证明所做的架构决策是合理的。

IEEE 42010:2011（ISO/IEC/IEEE 42010）标准定义了软件架构描述的核心概念模型，其核心要素及其关系如下（按标准框架分层解析）：

一、系统层（System Context）

关注系统（System-of-Interest）

• 指待描述的软件密集型系统或其组成部分，需明确系统边界与环境交互关系。
• 作用：锚定架构描述的范围，例如电商平台包含订单、支付等子系统。

涉众（Stakeholder）

• 与系统利益相关的角色集合（用户、开发者、运维、监管方等），其需求驱动架构设计。
• 关键要求：需识别不同涉众的优先级冲突（如业务部门要求快速迭代 vs. 安全团队要求严格审计）。

关注点（Concern）

涉众对系统的核心诉求，分为三类：

• 功能需求（如“支持每秒10万订单”）
• 质量属性（如可用性>99.99%、响应延迟<200ms）
• 约束（如“必须符合GDPR数据规范”）。

二、描述层（Architecture Description）

架构视点（Architecture Viewpoint）

定义如何构建特定类型视图的规则模板，包括：

• 目标受众（如运维视图面向基础设施团队）
• 覆盖的关注点（如部署视图聚焦容错性和资源利用率）
• 采用的模型类型（Model Kind）。

示例：逻辑视点描述功能模块划分，部署视点描述物理节点配置。

模型类型（Model Kind）

视点的建模语言规范，规定如何表达架构元素（如UML类图、BPMN流程图）。
典型分类：

• 结构模型（构件/连接件）
• 行为模型（数据流/状态机）
• 部署模型（节点/网络拓扑）。

架构视图（Architecture View）

基于特定视点生成的系统结构快照，是架构描述的核心输出。
组成元素：

• 构件（Component）：功能单元（如微服务、数据库）
• 连接件（Connector）：交互协议（如RPC、消息队列）
• 配置（Configuration）：拓扑关系与约束（如负载均衡策略）。

架构模型（Architecture Model）

• 视图的具体实例化表达，使用选定模型类型描述系统某方面结构。
• 示例：用部署图展示服务器集群与防火墙的物理连接关系。

三、关联与验证层（Correspondence & Rationale）

对应规则（Correspondence Rule）

• 强制不同视图间一致性的约束（如“逻辑层的订单服务必须映射到部署层的OrderService容器”）。

对应关系（Correspondence）

规则的具体实现实例，例如：

• 构件到代码模块的追踪（开发视图 → 代码视图）
• 服务到Kubernetes Pod的映射（逻辑视图 → 部署视图）。

架构理由（Architecture Rationale）

关键决策的背景与依据文档，需包含：

• 被选方案的优势（如选Kafka因支持百万级并发）
• 被否方案的缺陷（如RabbitMQ集群扩展性不足）。

四、整合框架（Architecture Description）

架构描述（Architecture Description）

包含上述所有要素的正式文档，需满足：

• 完整性：覆盖所有核心关注点
• 一致性：通过对应规则验证视图间逻辑
• 可审计性：架构理由支持决策追溯。

要素关联模型

此框架通过多视图分离关注点（如逻辑/开发/部署视图）、形式化模型（构件-连接件）及决策追溯（架构理由），解决了复杂系统描述的完整性、一致性与可演进性问题。

架构视图

架构描述包括架构的视图，视图的概念如图所示。根据他的观点，利益相关者对架构有不同的看法。这些观点是由每个利益相关者自己的特定关注点所驱动的。

IEEE 标准描述了多个“视图”，包括“功能视图”、“物理视图”和“技术视图”，这些通常被称为单独的架构或架构级别——例如，“功能架构”或“功能级别”。

架构观点
架构观点是用于构建、解释、使用和分析一种类型的架构视图的一组约定。观点包括模型种类、观点语言和符号、建模方法和分析技术，以框定一组特定的关注点。观点的示例有：操作、系统、技术、逻辑、部署、流程、信息。
架构视图
在 AD1 中的架构视图从一个或多个利益相关者的角度表达了所关注系统的架构，以解决特定的关注点，使用其观点所建立的约定。一个架构视图由一个或多个架构模型组成。

在其他架构方法中——例如，Kruchten 的 4 + 1 架构模型[Kru95]，视图是由不同图表中的不同描述元素所驱动的。例如，在 Kruchten 的逻辑视图中，重点是构建模块及其关系，而流程视图描述了流程以及它们之间的信息交换。
此外，相关文献经常提到许多不同的架构或架构级别。这些包括业务流程架构、IT 架构、功能架构级别、技术架构、技术基础设施架构、部署架构级别和许多其他术语

软件描述简单的概念模型

总之，可以说架构、架构层和视图这些术语在描述架构时使用得过于频繁。在此背景下，我们为软件架构的描述定义了一个简单的概念模型，如下图所示：

根据这个定义，一个架构描述由一系列的架构级别组成。一个架构级别将多个视图组合在一起，形成一个有意义的描述元素。视图包括文本和图表，它们又被存储在模型中。

以下是对各要素及其关系的结构化解析，并结合实例说明其实际应用：

根据您定义的软件架构描述概念模型，以下是对各要素及其关系的结构化解析，并结合实例说明其实际应用：

您描述的软件架构描述概念模型非常符合现代架构描述框架（如ISO/IEC/IEEE 42010）的核心思想。以下是对该模型的系统化解析与扩展，结合您提出的要素进行结构化说明：

---

架构描述概念模型

---

一、核心要素定义

要素	角色	实例
架构描述 (Architectural Description)	描述系统的完整架构文档	企业级电商平台架构说明书
架构层级 (Architectural Level)	逻辑分组单元，按关注点划分架构维度	功能架构层 / 技术架构层 / 安全架构层
视图 (View)	特定视角的可视化+文本表述，覆盖层级内一个关注点	功能层的"订单流程视图"（含UML图+文本）
图表 (Diagram)	视图中的结构化图形表达	C4上下文图 / 时序图 / 部署图
自由文本 (Free Text)	视图中非结构化的解释性内容	设计约束说明：“支付服务必须满足PCI-DSS合规”
模型 (Model)	存储视图元素的结构化数据源（可机读）	ArchiMate模型文件 / PlantUML代码库
架构决策 (AD)	关键设计选择的理由，贯穿文本描述	“选用Kafka而非RabbitMQ：需支持百万级订单/日吞吐（基准测试报告链接）”

---

二、层级-视图-内容的映射关系

示例：订单系统功能架构层级

视图类型	图表	自由文本内容	存储模型
静态结构视图	组件依赖图	• 组件职责定义 • 接口契约说明	Enterprise Architect模型
动态行为视图	订单状态机图	• 超时取消规则 • 支付失败处理流程	Draw.io XML
纯文本视图	无图表	• 业务规则列表 • 架构决策基本原理	Confluence文档

📌 关键特征：
同一层级内多视图互补（如静态图展示结构 + 动态图展示流程），文本提供上下文解释

---

三、自由文本的核心作用

1. 不可替代性场景

场景类型	图表局限	自由文本解决方案
设计决策追溯	图表无法表达选择理由	记录备选方案对比及选定依据
非功能性需求	图形难以描述SLA量化指标	明确"响应时间≤500ms (P99)"
业务规则	流程图无法覆盖复杂条件逻辑	用决策表描述优惠券使用规则
合规性要求	无标准图形表示	文本声明"遵循GDPR第32条数据加密标准"

2. 纯文本层级的典型用例

层级名称	内容
架构原则层	• 技术选型原则：“优先选用云托管服务” • 设计规范：“所有接口必须幂等”
风险治理层	• 已知风险：“单点故障：数据库主从延迟” • 缓解措施：“读写分离+缓存补偿”
演进路线层	• 迁移计划：“2024Q1弃用单体架构，分阶段微服务化”

---

四、模型作为存储介质的价值

1. 模型驱动的架构描述

• 双向同步：代码变更 → 反向更新模型（如JPA实体修改触发Er图刷新）

2. 模型类型与工具

模型类型	存储内容	工具
结构模型	组件/类/数据库表关系	UML工具（StarUML）
行为模型	流程/状态转换	BPMN工具（Camunda）
部署模型	节点/容器/网络拓扑	HasiCorp Terraform
决策模型	ADR链接库	MADR（Markdown ADRs）

---

五、实践建议：分层描述框架

Level 1：业务架构层

# 视图：订单价值链视图
## 图表
![[Order Value Chain.svg]]
## 自由文本
- **决策AD-003**：  选用事件驱动架构 → 支持商家实时结算（见[基准测试]）
- **业务规则BR-112**：  跨境订单需额外征收关税（税率表链接）

Level 2：应用架构层

# 视图：服务依赖视图
## 图表
```plantuml
[订单服务] --> [支付服务] : 同步调用
[订单服务] --> [库存服务] : 异步事件

自由文本

• 接口协议：
  支付服务响应时间≤200ms（SLA-2023-v1）

#### **Level 3：纯文本治理层**
```markdown
# 安全治理规范
- **加密标准**：  敏感字段必须AES-256加密（符合NIST SP 800-131A）
- **审计要求**：  所有操作日志保留≥2年

---

六、反模式警示

问题	后果	改进方案
图表与文本割裂	时序图未标注超时处理逻辑	在图表旁添加注释箭头指向说明文本
决策记录分散	ADR散落在邮件/会议纪要中	用MADR模板集中存储到决策目录
模型不更新	代码已重构但组件图仍为旧版	CI流水线自动校验模型-代码一致性
过度依赖自由文本	千页Word文档难以维护	结构化文本（AsciiDoc/DITA）

---

七、工具链整合参考

核心价值：通过此模型实现三统一

• 表达统一：图形化抽象 + 文本精准描述
• 存储统一：模型作为唯一可信源
• 追溯统一：从业务目标到代码实现的完整链条

架构描述与架构级别

正如已经解释的那样，架构在不同的级别上进行描述。这些级别选择和组织为相关的设计方法提供了一个初始参考点。架构级别经常出现在不同的抽象层次上——例如，高层次的“面向服务的分层架构”风格，或者更具体的包括功能实体和服务的功能架构级别。

所有这些架构方法中的方法论都是基于将相关的描述和细化方法在两个维度上进行分离。在视角维度上，处理不同的架构领域（如数据、流程、服务和程序组织）。在抽象程度维度上，这些不同的架构领域被逐步详细地处理和描述。一旦您理解了这种方法，在这些架构框架中导航就会相对容易。

下图展示了将架构描述细分为四个架构级别：架构风格、技术基础设施、功能应用架构级别（也称为 A 架构）和技术架构级别（T 架构）。如下所示，这四个级别在两个维度上有所不同——换句话说，在抽象级别和视角（功能与技术）方面。

正如级别之间的箭头所示，架构级别可以单独处理，尽管它们相互影响，因此相互依赖。更具体的功能和技术架构级别自然涉及到架构风格和技术基础设施的要求。在一个方向上，功能和技术架构级别的具体设计影响更高架构级别的要求。在另一个维度中也可以找到类似的关系。例如，技术架构为持久性或事务管理提供了特定的概念，这些反过来又必须包含在功能架构级别中。在另一个方向上，功能架构级别提供了所需持久性概念方面的输入。

这里的架构风格是系统的核心架构隐喻。例如：“我们的软件系统构建为三层架构，在表示层使用模型 - 视图 - 控制器，在数据管理层使用对象 - 关系映射。”另一方面，技术基础设施定义了架构的网络配置。例如：“我们有一个带有网络和应用容器以及关系数据库的简单客户端。”

功能和技术架构级别的基于视图的描述发生在更详细的架构级别。在功能架构级别，为实现功能需求设计适当的应用构建模块及其关系。例如，可以在此为通用保险产品模型创建设计，以便在应用中映射不同的保险产品。

相比之下，在技术架构级别，基于非功能需求为相关方面设计并记录跨学科的解决方案构建模块。例如，可能需要对所有功能实体进行版本控制，并在技术架构中为此开发解决方案。然后，应用架构级别的功能实体可以使用来自技术架构级别的这个通用解决方案。

以下是对这四个级别的详细解析，突出它们在两个维度上的位置以及核心内容和关注点：

架构级别	抽象级别 (高 -> 低)	视角	核心内容与关注点	典型视图/模型/自由文本内容
1. 架构风格	最高	混合	系统整体的结构模式、设计哲学和核心约束。 定义了系统的基本“形状”和交互原则。	* 模型/图表： 架构风格示意图 (如分层图、微服务组件图、事件流图、管道-过滤器图)。 * 自由文本： 选择的理由（Rationale）、核心原则、约束（如通信协议、数据一致性模型）、适用场景分析、与其他风格比较。
2. 技术基础设施	高	技术	支撑应用运行的通用平台、服务和技术底座。 关注环境和平台能力。	* 模型/图表： 基础设施拓扑图、网络架构图、云服务组件图 (如 VPC, Subnets, IAM 结构)、中间件部署图。 * 自由文本： 平台选型依据、关键配置原则、SLA 目标、安全基线、容量规划策略、运维模式说明。
3. 功能应用架构级别	中	功能	应用的核心功能逻辑、组件划分、数据流和业务行为。 关注系统做什么以及内部结构。	* 模型/图表： 组件图、部署图 (应用组件视角)、类图 (核心领域模型)、序列图、活动图、状态图、数据流图 (DFD)。 * 自由文本： 关键业务功能分解、组件职责定义、接口契约、核心业务流程描述、数据模型说明、关键设计决策及Rationale、非功能性需求 (如性能关键路径) 在功能设计中的考虑。
4. 技术架构级别	最低/最具体	技术	实现功能应用的具体技术选型、组件设计、配置细节。 关注如何构建。	* 模型/图表： 详细部署图 (实例级)、类图 (实现细节)、序列图 (含技术组件交互)、数据库物理模型、API 详细设计图、框架/库依赖图。 * 自由文本： 具体技术栈选型理由、框架配置细节、关键算法描述、数据库表结构及索引设计说明、API 接口规范、日志监控方案、安全实现细节、编码规范要点、特定性能优化措施。

关键优势分析

1. 维度清晰，覆盖全面：
   • 抽象维度： 从最抽象、最战略性的“为什么选择这种风格”（架构风格），到最具体、最战术性的“这个类/表/API如何实现”（技术架构级别），层层递进，没有遗漏。
   • 视角维度： 明确区分了功能（系统能力、业务逻辑）和技术（实现手段、运行平台），避免了概念混杂。技术基础设施和技术架构级别都属技术视角，但处于不同抽象层。
2. 职责分明，减少混淆：
   • 每个级别有明确的定位和核心关注点。例如，“使用Kafka”是技术架构级别的选型；而“采用事件驱动架构”则是架构风格的决策；“部署在AWS EKS集群”是技术基础设施的范畴；“订单服务如何通过事件处理库存扣减”是功能应用架构级别的核心逻辑。
3. 促进沟通与理解：
   • 不同角色可以聚焦于相关的级别：高管/业务分析师关注架构风格和功能应用架构；基础设施/运维团队关注技术基础设施；应用开发/技术负责人关注功能应用架构和技术架构级别。
4. 支持决策与演进：
   • 高层决策（如架构风格、基础设施平台）的影响可以清晰地向下追溯。
   • 底层需求（如性能瓶颈、技术债）可以向上反映到更高层次进行战略调整。
   • Rationale 的嵌入（尤其在风格和关键设计决策中）为未来的变更评估提供了依据。
5. 灵活性：
   • 每个级别内部可以包含多种视图（如功能应用架构级别可以有组件结构视图、业务流程视图、数据视图）。
   • 自由文本作为必要补充，确保了关键的非结构化信息（理由、背景、解释）得以记录。

实践建议

1. 明确映射关系：
   • 在文档或工具中清晰标识每个描述元素属于哪个架构级别和视角。
   • 建立级别间的可追溯性链接（例如，功能应用架构中的组件需要部署到技术基础设施中的某个平台）。
2. 工具支持：
   • 使用支持分层建模和视图管理的架构工具（如 Sparx EA, Archi, Structurizr, LeanIX, Bizzdesign）来有效管理这四个级别及其内容。
3. 受众导向：
   • 根据受众（如开发团队、运维、管理层）裁剪不同级别的详细程度。技术架构级别对开发团队最详细，对管理层则高度概括。
4. 持续演进：
   • 架构是演进的，确保这四个级别的文档随着系统发展而更新，尤其关注决策Rationale的变更。

总结

您定义的这个四级别模型（架构风格、技术基础设施、功能应用架构级别、技术架构级别），结合抽象级别和功能/技术视角两个维度，是一个非常成熟且实用的软件架构描述框架。它结构清晰、覆盖全面、职责分明，能够有效地指导架构的设计、沟通、实施和维护，是构建高质量、可理解、可演进软件系统的有力工具。这个模型很好地体现了架构思考的层次性和多角度性。