docs(architecture): 更新架构定义和4+1视图说明并添加架构反模式章节

更新架构定义，将"长期可复用的设计决策"改为"重要且难以逆转的设计决策"，
修正4+1视图中实现视图为开发视图，部署视图为物理视图，并完善各视图的说明表格。

新增架构反模式与误区章节，涵盖决策类、复用类、时间维度、范围维度、架构图绘制、
认知类反模式，以及架构原则应用误区和避免反模式的核心原则。

Author: 0xcaffebabe

doc/软件工程/架构/架构.md

@@ -12,7 +12,7 @@ books: [
 
 软件架构（Software Architecture）是一种用来管理复杂性的工程学科，其目标是在软件系统漫长生命周期中，在有限条件下做最优权衡，构建、演进、运行并维护系统。它不仅满足非功能性需求（可维护性、可扩展性、可靠性、可测试性、可部署性），更承担沟通、决策、治理等组织层面的职能。
 
-架构本质上是一组**长期可复用的设计决策**，这些决策定义了系统的组织结构、组件及联系、行为协作、限制与约束，并指导系统的持续演化。架构作为团队协作的契约，约束不同模块/服务间的交互方式，使团队在系统演进过程保持一致性与可替换性。
+架构本质上是一组**重要且难以逆转的设计决策**，这些决策定义了系统的组织结构、组件及联系、行为协作、限制与约束，并指导系统的持续演化。架构作为团队协作的契约，约束不同模块/服务间的交互方式，使团队在系统演进过程保持一致性与可替换性。
 
 ## 架构的本质
 
@@ -232,6 +232,7 @@ books: [
 * **Rule**：基于关键场景绘制协作方式
 
 ### 4+1 视图
+
 ```
 ┌─────────────────────────────────────────────────────────┐
 │                      场景 (Scenarios)                   │
@@ -243,29 +244,32 @@ books: [
 └─────────────────────────────────────────────────────────┘
         ↑                    ↑                    ↑
    ┌────┴────┐          ┌────┴────┐          ┌────┴────┐
-   │ 逻辑视图 │          │ 实现视图 │          │ 进程视图 │
-   │ Logical │          │Impl View│          │ Process │
+   │ 逻辑视图 │          │ 开发视图 │          │ 进程视图 │
+   │ Logical │          │ Dev View│          │ Process │
    └────┬────┘          └────┬────┘          └────┬────┘
         ↑                    ↑                    ↑
-   开发人员创建            构建系统创建         运行组件描述
-   类/包 + 关系          模块(JAR/WAR)        进程 + IPC
-                        + 依赖关系
+   最终用户/业务人员       开发人员/配置管理员    系统集成人员
+   领域模型、职责         代码组织、分层依赖      线程、并发、同步
+   接口契约                                     进程 + IPC
                                                ┌────┴────┐
-                                               │ 部署视图 │
+                                               │ 物理视图 │
                                                │Physical │
                                                └────┬────┘
                                                     ↑
-                                               机器 + 进程
-                                               网络连接
+                                               系统工程师/运维
+                                               机器、容器部署
+                                               网络拓扑
 ```
 
-包含：
+**各视图说明**：
 
-* 逻辑视图：领域、职责、接口
-* 实现视图：代码结构、构建依赖
-* 进程视图：运行时交互
-* 部署视图：机器、容器部署关系
-* 场景视图：用户视角的用例与时序
+| 视图 | 别名 | 关注点 | 主要受众 |
+|------|------|--------|----------|
+| 逻辑视图 | Logical View | 功能需求、领域模型、接口契约 | 最终用户、业务人员 |
+| 开发视图 | Development View | 代码组织、分层结构、模块依赖、构建配置 | 开发人员、配置管理员 |
+| 进程视图 | Process View | 运行时行为、并发同步、通信机制 | 系统集成人员 |
+| 物理视图 | Physical View | 硬件映射、分布式部署、网络拓扑 | 系统工程师、运维 |
+| 场景视图 | Scenarios View | 用例、业务流程、视图串联验证 | 测试人员、分析师 |
 
 ### 各类常见架构图
 
@@ -338,6 +342,16 @@ books: [
 
 架构并非单一视角，而是多种思想共同构成的认知框架。不同流派从不同角度解释"什么是架构"，它们并非互斥，而是互补关系。理解这些流派有助于在复杂系统中选择更合适的架构方式。
 
+> | 层次 | 回答的问题 | 包括 |
+> |------|------------|------|
+> | **架构定义流派** | "架构是什么"的本体论 | 结构派、决策派 |
+> | **架构设计方法论** | "如何做架构设计"的方法论 | 模式派、领域驱动派、进化派、系统论派、工程派 |
+>
+> - **定义流派**是元问题的分歧：当给架构下定义时，选择从哪个角度描述它？结构派说"架构是组件+连接"，决策派说"架构是重要决策的集合"
+> - **设计方法论**建立在定义之上：当知道架构是什么，用哪些视角来指导设计？可以用模式、可以用领域边界、可以用演化思维、可以用系统动力学、可以用工程治理——这些是不同切入角度，不影响架构"是什么"的本质。
+>
+> 类比：定义流派像"哲学基本问题"，设计方法论像"解决问题的方法"。
+
 ### 结构派
 
 关注系统由哪些模块组成，以及模块如何连接。
@@ -408,6 +422,93 @@ books: [
 
 适用：中大型组织、要求高可靠性的行业。
 
+## 架构反模式与误区
+
+架构反模式是那些看似合理但会导致架构失败的常见错误。与架构模式相对，反模式揭示"如何不做"而非"如何做"。理解反模式是避免失败的前提。
+
+### 决策类反模式
+
+| 反模式 | 特征 | 危害 |
+|-------|------|-----|
+| **HiPPO 主导** | 个人（收入最高者）决定所有架构决策 | 决策反映个人偏见，团队不支持执行困难 |
+| **功能驱动** | 架构由功能需求而非质量属性需求驱动 | 系统性能、扩展性、弹性不足 |
+| **外包决策** | 将架构决策外包给供应商或顾问 | 丧失控制，不理解自身 QAR |
+
+**核心问题：** 架构决策必须由团队基于数据和论证做出，必须由 QAR（质量属性需求）驱动，必须理解每个决策的上下文和权衡。
+
+### 复用类反模式
+
+| 反模式 | 特征 | 危害 |
+|-------|------|-----|
+| **为复用牺牲质量** | 强行复用不匹配当前 QAR 的架构 | 被遗留技术限制，维护成本超过重新开发 |
+| **复制成功架构** | 不理解上下文就复制大公司/文章的成功架构 | 忽略权衡差异，走上失败道路 |
+| **框架控制架构** | 让框架的隐式决策接管应用 | 丧失底层理解，升级/替换困难 |
+
+**核心问题：** 复用必须基于 QAR 匹配。复制架构必须理解其上下文和权衡。框架是工具，不是架构本身。
+
+### 时间维度反模式
+
+| 反模式 | 特征 | 危害 |
+|-------|------|-----|
+| **超前大架构** | 试图一次设计完美架构，预判所有变化 | 资源巨大，周期漫长，无法适应实际反馈 |
+| **牺牲质量换速度** | 专注 MVP 忽视 MVA，"以后重构" | 技术债务指数积累，重构成本远超预期 |
+| **过度延迟交付** | 为完善架构不断推迟发布 | 缺乏实际反馈，延误业务价值 |
+
+**核心问题：** 架构是持续过程，不是一次性事件。MVP 与 MVA 需要平衡。没有完美架构，只有基于当前信息的合理选择。
+
+### 范围维度反模式
+
+| 反模式 | 特征 | 危害 |
+|-------|------|-----|
+| **过度泛化** | 设计通用架构适配所有场景 | 臃肿无用，满足不了任何场景的真实 QAR |
+| **过度设计** | 用复杂性换想象中的灵活性 | 增加维护负担，延长开发周期 |
+| **忽视边界** | 不考虑未来变化，"先用再说" | 技术债务快速积累，变化成本指数增长 |
+
+**核心问题：** 过度设计常比不足设计更糟糕。猜错边界的代价远大于慢慢改的代价。代码可以删掉，概念和抽象删不掉。
+
+### 架构图绘制反模式
+
+| 错误类型 | 问题 |
+|---------|-----|
+| 语义不清 | 形状/线条/颜色含义不明，无图例说明 |
+| 层级混杂 | 运行时元素与静态元素混在同一图 |
+| 信息过载 | 一张图试图表达所有内容 |
+| 图文分离 | 依赖口头说明，图本身不自治 |
+
+**核心问题：** 架构图必须自解释、一致、准确，与代码保持语义同步。自动生成与手动创建结合优于纯手动维护。
+
+### 认知类反模式
+
+| 反模式 | 问题 |
+|-------|-----|
+| **重结构轻决策** | 只关注组件和连接，忽视决策过程 | 导致知识失传，无法复制决策逻辑 |
+| **架构即委员会** | 架构脱离开发，由委员会设计 | 设计与实现脱节，无法落地 |
+| **文档至上** | 认为文档详细=架构好 | 文档可能过时，代替不了实际验证 |
+
+**核心原则：** 架构是一系列重要且难以逆转的**决策**。文档和图不是架构，它们只是决策的载体。决策的**质量**和**可见性**才是核心。
+
+### 架构原则应用误区
+
+| 原则 | 常见误用 | 正确理解 |
+|-----|---------|---------|
+| **KISS** | 简单优于一切 | 简单是手段；过度简单可能导致复杂性转移 |
+| **DRY** | 绝对不能重复 | 有意重复 vs 无意重复；错误的抽象比重复更贵 |
+| **演化** | 不做初始设计 | 初始设计必要；演化是持续改进，不是拒绝设计 |
+| **合适** | 用成熟技术就好 | 匹配团队能力和 QAR；新技术需验证成本 |
+
+### 避免反模式的核心原则
+
+1. **QAR 驱动** — 质量属性需求决定架构，非功能需求或业务压力
+2. **决策可见** — 隐式决策变显式，记录原因、权衡、替代方案
+3. **平衡权衡** — 无完美架构，只有特定上下文的最优选择
+4. **渐进演化** — 架构是持续活动，基于实际反馈迭代改进
+5. **团队共识** — 多元视角挑战假设，避免 HiPPO 和委员会两极
+6. **上下文匹配** — 复制必须理解上下文和权衡
+7. **验证优先** — 实际运行反馈优于理论评审
+8. **保持简单** — 在满足 QAR 前提下尽量简单
+
+> "好的判断来自经验，而经验大多来自糟糕的判断。" — 反模式的价值在于让人们不必亲自犯所有错误就能获得判断力。
+
 ## 架构治理
 
 架构不仅是技术问题，更是治理问题。治理的目标是让架构在组织规模扩张过程保持一致性与可控性。