架构设计

定位：这是一个面向架构师的高级知识体系文档，聚焦架构设计背后的原理、模型、方法论与决策哲学，为复杂系统建设提供可复用的认知框架。

1. 架构设计的本质

架构设计的核心任务不是选择技术，而是组织复杂性。其本质可归纳为三件事：

  1. **抽象复杂性**：识别系统“难以改变的部分”，形成稳定结构。
  2. **约束系统边界**：通过模型、原则、接口与契约保持系统可控。
  3. **降低长期成本**：让系统能在不推翻原有结构的情况下持续演进。

因此，架构是一种 约束 + 构造 + 演化 的综合能力，而非对代码结构的静态描述。

2. 架构设计要素体系

原文的“架构设计要素”较为散乱，下面将其抽象为一个稳定的概念体系。

2.1 架构规划：战略层

目标：做正确的系统，而不是把系统做正确。

规划解决的问题：

输出是可落地、可迭代的架构蓝图，同时明确约束、边界和演进路线。

2.2 架构分解：结构层

通过“分而治之”将需求与复杂性拆解为可实现的模块。

设计分解遵循三个原则：

  1. **分解粒度**：粒度越细成本越高，粒度越粗耦合越强，需要寻找“认知分界”。
  2. **稳定性中心化**：优先将不易改变的部分抽象出来（领域对象、契约、平台层）。
  3. **演化式设计**：架构不是一次性交付，而是迭代演化的系统。

2.3 架构输入：系统之“约束空间”

架构的设计空间由以下四类输入共同定义：

输入类型内容架构意义
功能性需求系统做什么确定功能性模型、边界
非功能需求性能、可用性、弹性、扩展性驱动架构风格选择
限制条件团队、预算、法规、安全决定可行空间
现有资产与技术存量系统、技术栈决定系统兼容性与迁移成本

架构的可行性由这些因素共同决定，而非单一技术选择。

2.4 架构输出：系统蓝图体系

结构化后的架构输出通常包含五类蓝图：

  1. **架构规划蓝图**：目标、范围、愿景、阶段路线图
  2. **研发设计蓝图**：架构模型、组件关系、契约、边界
  3. **测试蓝图**：验证策略、质量属性验证体系
  4. **部署蓝图**：物理拓扑、管控体系、发布策略
  5. **采购蓝图**：RFP、POC、技术决策依据

3. 架构设计原则

原文原则过于工程化，下面将其抽象为普适的架构哲学。

3.1 合适优于先进（Pragmatism）

过度追求先进技术会增加复杂性与不可控性。架构应追求稳态、可解释性、与组织能力匹配。

3.2 简单优于复杂（Simplicity）

软件复杂度会自然增长，架构必须主动控制复杂性。KISS、YAGNI、最小可行结构（MVS）是核心方法。

3.3 演化优于一步到位（Evolution）

系统必然演化，提前构建“可演化能力”比提前构建“未来能力”更重要。变与不变应清晰分离。

4. 架构设计方法论

4.1 识别复杂性：架构设计的起点

复杂性来源四类因素：

复杂性维度示例架构任务
业务复杂性高耦合业务规则领域建模、聚合设计
技术复杂性分布式、并发技术风格、基础设施能力
操作复杂性监控、部署、容量可观测性、运维架构
组织复杂性人员能力、协作方式治理体系、边界划分

“倒找法”是发现隐性复杂度的有效方式：从已知问题 → 找到系统对应问题 → 反推复杂性来源

4.2 多方案设计：避免认知锁定

架构师必须规避“单点思维陷阱”。因此：

归根结底，备选方案的价值不在于选择，而在于扩展设计空间。

4.3 质量属性驱动的架构评估（ATAM 思想简化版）

步骤：

  1. 列出关键质量属性（性能、可用性、扩展性、安全性…）
  2. 按业务阶段排序
  3. 对每个架构方案逐项评估其满足度
  4. 找到风险点、敏感点、折衷点

架构评估本质上就是找到“系统折衷面”与“长期成本曲线”。

4.4 详细方案设计：模型到工程的桥梁

进入详细设计说明方案是“可构建的系统”，而非理念。

需要特别关注：

5. 架构视图体系

下面将原来分散的模型统一为“六视图架构框架”。

5.1 架构立方体（Cube Model）

这是对系统的六个本质维度的抽象：

维度描述解决的问题
应用视图系统提供的核心能力我们提供什么？
技术视图数据库、中间件、基础设施系统运行在什么上？
功能视图业务逻辑分解业务如何组织？
运行视图部署、运行时状态系统如何运行？
逻辑视图抽象的系统结构系统如何分解？
物理视图物理节点、拓扑系统如何落地？

这是一个从抽象到现实的分层模型。

6. 需求分析体系

6.1 需求贯穿系统全生命周期

需求是架构的约束来源，包括：

6.2 V-模型（系统级方法论）

你原文的描述极为详细，我在此抽象为：

左侧：定义系统右侧：验证系统中间：构建系统

核心思想：

7. 模块定义与系统边界

7.1 高内聚、低耦合：永恒原则

模块边界定义的是：

粗粒度模块 ≠ 简单细粒度模块 ≠ 高质量边界的关键是是否对“变化”敏感。

7.2 系统上下文（Context Diagram）

系统上下文图用于定义：

它是“架构边界”的最底层事实。

8. 架构模型体系

以下模型是架构师的基础建模工具：

模型目的适用阶段
用例模型描述用户价值和系统能力分析
领域模型识别业务不变性架构
鲁棒图用例到对象模型的桥梁分析→设计
时序图描述行为流程设计
ER 图数据建模数据架构
整体架构草图快速表达结构架构

9. 运行性模型（Run-time Model）

运行视图关注系统在真实世界中的状态：

运行视图的重点不是图，而是：

10. 架构治理与演进

真正的架构价值不在于设计，而在于让系统可持续演进：

关键治理能力：

  1. **统一的模型语言**
  2. **标准化边界定义**
  3. **技术雷达与演进策略**
  4. **质量属性监控与反馈**
  5. **架构决策记录（ADR）**
  6. **组合式能力的可演化性**

架构的终局不是完美，而是 "可改变且不崩溃"。

关联内容（自动生成）