什么是架构

学习目标

• 能解释“什么是架构”如何从系统行为与结构、政策与细节、边界与依赖三组坐标判断一项决策是否具有架构影响
• 能逐项定位 策略与细节、行为与结构、边界与组件、保持选择余地、可测试性与可替换性，并说明每个概念在当前来源边界内承担什么责任
• 能按 列出关键行为 → 识别变化原因 → 划出组件边界 → 反转细节依赖 → 执行替换测试 推演“替换数据库”，检查“业务政策不因界面、数据库或框架替换而失效，关键行为可以在外部细节缺席时验证”
• 能注入“把当前框架、部署拓扑或数据库品牌直接等同于系统架构”，依据依赖清单、组件职责、关键用例测试、替换实验与被推迟的不可逆决策记录定位越界、撤销并用同一情境重放

为什么从“把架构视为保护高层政策、控制依赖和延迟细节决策的结构，而不是一张技术产品清单”开始

从系统行为与结构、政策与细节、边界与依赖三组坐标判断一项决策是否具有架构影响。本页先画责任和依赖，再沿具体情境执行决策，最后主动制造一个边界违规；这种顺序把术语变成可以验证、推翻和恢复的设计合同。

“什么是架构”不是技术采购建议。它处理的是规则放在哪里、模型在哪个语境内成立、哪些变化可以被隔离，以及团队如何判断一条边界已经被穿透。最终功能可运行，只能证明快乐路径存在，不能证明结构允许安全演进。

来源、版次与课程边界

Pearson 页面仅用于核定书名、作者、版次与目录范围；本页可公开核对的架构边界结论主要来自 Martin 的原始 Clean Architecture 文章，并作独立中文重写。

本专题不是某一本既有书的中文版，也不是把多位作者的文章拼成“原著章节”。课程主干分别取自 Eric Evans 的领域驱动设计体系与 Robert C. Martin 的整洁架构体系；CQRS、事件溯源和六边形架构始终标为扩展。以下链接承担不同事实责任：

• Pearson: Clean Architecture：核对 Robert C. Martin、第一版、2017 年与正式目录范围
• Robert C. Martin: The Clean Architecture：核对独立性目标、四层、依赖规则、跨边界控制流与简单边界数据

本页采用独立中文重写。能从公开全文或授权摘要核对的定义才作为来源事实；项目情境、交互实验、取舍表和练习答案均为本站教学设计。

核心概念与可观察责任

策略与细节

策略表达系统为什么存在以及必须遵守的业务规则；细节是实现策略的设备和机制，例如 Web、数据库或消息系统。 在“替换数据库”中，观察重点是业务政策不因界面、数据库或框架替换而失效，关键行为可以在外部细节缺席时验证。

行为与结构

软件必须完成当前行为，也必须保留可持续修改的结构；只看功能通过会掩盖依赖扩散带来的长期改变成本。 在“新增界面”中，观察重点是依赖清单、组件职责、关键用例测试、替换实验与被推迟的不可逆决策记录。

边界与组件

组件边界把变化原因不同的职责分开，并通过明确接口协作；边界价值体现在一侧变化时另一侧无需被迫修改。 在“替换数据库”中，观察重点是业务政策不因界面、数据库或框架替换而失效，关键行为可以在外部细节缺席时验证。

保持选择余地

架构要推迟尚无证据支持的数据库、框架和通信细节，让重要决策在获得更多信息后仍可改变。 在“新增界面”中，观察重点是依赖清单、组件职责、关键用例测试、替换实验与被推迟的不可逆决策记录。

可测试性与可替换性

若业务规则只有启动真实界面和数据库才能验证，说明细节已经穿透边界；可独立测试是依赖方向正确的可观察结果。 在“替换数据库”中，观察重点是业务政策不因界面、数据库或框架替换而失效，关键行为可以在外部细节缺席时验证。

一条可执行的设计判断

本页采用以下判断链：把架构视为保护高层政策、控制依赖和延迟细节决策的结构，而不是一张技术产品清单。正常情况下必须持续保持“业务政策不因界面、数据库或框架替换而失效，关键行为可以在外部细节缺席时验证”；反例“把当前框架、部署拓扑或数据库品牌直接等同于系统架构”只改变一个关键条件，便于定位因果。

观察项	本页合同
最小正常情境	订单规则不变，只把关系数据库改为文档存储
边界或迁移情境	在既有 Web 入口之外增加批处理入口
必须保持	业务政策不因界面、数据库或框架替换而失效，关键行为可以在外部细节缺席时验证
首要违规	把当前框架、部署拓扑或数据库品牌直接等同于系统架构
验收证据	依赖清单、组件职责、关键用例测试、替换实验与被推迟的不可逆决策记录

先预测，再操作三个本页实验

⚡分步1 / 3

1. 1
2. 2
3. 3

重置

实验一：边界与模型地图

操作前先预测“替换数据库”里哪一侧拥有规则、哪一侧只是技术或协作细节。切换概念和情境后，检查“把架构视为保护高层政策、控制依赖和延迟细节决策的结构，而不是一张技术产品清单”是否仍能解释三块区域的责任。

Boundary model

什么是架构：边界与责任地图

从系统行为与结构、政策与细节、边界与依赖三组坐标判断一项决策是否具有架构影响

切换最小情境

替换数据库新增界面

定位正式概念

策略与细节行为与结构边界与组件保持选择余地可测试性与可替换性

architecturedomaindesign-01 · 当前观察

策略与细节：订单规则不变，只把关系数据库改为文档存储

区域 1业务政策

定义系统目的与稳定规则

↓

区域 2应用边界

编排用例并隔离变化

↓

区域 3外部细节

界面、数据库、框架与设备

情境验收

业务政策与用例测试不变，改动集中在外部适配器

上一步播放下一步

易错边界与取舍

练习与答案

练习

问题 1：概念—边界—证据对照。 完成以下逐项核对：

1. 策略与细节：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
2. 行为与结构：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
3. 边界与组件：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
4. 保持选择余地：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
5. 可测试性与可替换性：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。

查看答案

对每个概念先确定它属于业务政策、模型协作还是外部技术，再画允许的依赖方向。用“订单规则不变，只把关系数据库改为文档存储”建立正常基线，用“把当前框架、部署拓扑或数据库品牌直接等同于系统架构”作为单一反例，最后从依赖清单、组件职责、关键用例测试、替换实验与被推迟的不可逆决策记录中找第一处不一致。

问题 2：最小情境推演。 怎样验证“替换数据库”没有靠最终功能碰巧通过？

查看答案

按 列出关键行为 → 识别变化原因 → 划出组件边界 → 反转细节依赖 → 执行替换测试 保存每步状态，预期结果是“业务政策与用例测试不变，改动集中在外部适配器”。最终输出之外，还要逐步确认“业务政策不因界面、数据库或框架替换而失效，关键行为可以在外部细节缺席时验证”；任一中间状态越界都应拒绝当前设计。

问题 3：替代方案与恢复。 注入“把当前框架、部署拓扑或数据库品牌直接等同于系统架构”后，怎样比较修复与更简单方案？

查看答案

先保留故障前的依赖清单、组件职责、关键用例测试、替换实验与被推迟的不可逆决策记录，再记录首个越界位置。分别实施最小修复和删除多余模式的方案，用同一个“在既有 Web 入口之外增加批处理入口”重放；选择仍满足“新入口调用同一应用边界，不复制业务规则”且依赖更少的方案。

本页小结

• 什么是架构的核心判断是：把架构视为保护高层政策、控制依赖和延迟细节决策的结构，而不是一张技术产品清单。
• 正常路径以“业务政策与用例测试不变，改动集中在外部适配器”验收，不能只检查接口返回成功。
• 边界路径以“新入口调用同一应用边界，不复制业务规则”验收，并保存依赖清单、组件职责、关键用例测试、替换实验与被推迟的不可逆决策记录。
• 如果“把当前框架、部署拓扑或数据库品牌直接等同于系统架构”仍可静默通过，说明边界只是图示，没有成为可执行约束。