什么是架构

架构的定义、架构与设计的区别、架构决策的影响范围与架构师的角色。

为什么只记结论不足以掌握什么是架构

学习“什么是架构”时,第一步不是记住结论,而是冻结输入、上下文、版本和成功标准。只有这些条件明确,什么是架构的含义才不会随着样例变化。正文已有的概念说明要与结构图、运行轨迹和失败样本互相印证,不能只凭最终输出看似正确就宣布完成。

结构分析从核心概念开始:列出参与者、职责、连接方向、生命周期和所有权,再沿正常路径追踪数据或控制流。每一条边都要说明为什么存在、谁创建、谁消费、谁负责清理;如果边界被跨越,必须能在证据中找到第一处异常。

机制验证要把常见误区写成可以执行的条件。正常样本证明主路径,恰好边界样本验证等号和空值,单故障样本只破坏一个假设。三类样本使用同一份观察指标,避免因为测试口径变化而把偶然结果误认成规律。

成本分析同时记录时间、空间、延迟、耦合、可维护性和不可逆操作。小结与练习不是一句“可能失败”,而是可复现输入、预期停点、实际轨迹、错误分类与清理步骤。任何自动重试都要有次数、预算和幂等边界。

方案比较不能只列优点。需要给出直接实现、当前方案和至少一个替代方案,逐项比较复杂度、扩展点、故障隔离和团队认知成本。当问题规模很小或变化轴稳定时,更简单的实现往往更好;模式与框架必须由真实变化压力证明。

实现阶段把大结论拆成可检查的中间产物:配置快照、结构清单、状态转移、输入输出样本、日志摘要和测试结果。每个产物带来源与生成命令,下一阶段只消费已通过门禁的版本,避免旧缓存或隐式默认值污染结论。

解释结果时必须区分相关性与因果性、接口承诺与实现细节、设计意图与运行事实。对“名词解释”的判断要由独立证据支持,并明确适用范围;一旦输入分布、版本、硬件或组织边界改变,就重新运行最小实验。

复盘从首个分叉开始,而不是从最后一个报错倒推。先比较冻结输入,再比较第一份结构化中间产物,随后检查状态、约束和副作用。这样可以把复杂系统的排错范围收缩到一个阶段,避免在多个层次同时修改造成新的不确定性。

迁移到真实项目时,先选择一个最小但有代表性的切片,保存改造前基线,再逐步引入“什么是架构”中的机制。每一步只改变一个变量并保留回滚点;性能、正确性、安全性和可理解性至少各有一项可量化指标。

最终验收要求读者能脱离页面重新画出结构、口述关键链路、实现最小版本、构造一个反例并解释失败位置。若只能复述名词而不能预测中间状态,说明知识仍停留在识记层,需要回到图示和实验重新验证。

本页用、

、、、建立统一坐标。先预测这些概念在结构图和运行轨迹中的位置,再操作实验控件;如果结果与预测不一致,停止在首个分叉,不要用后续补丁掩盖早期错误。

权威目录与核心概念逐项对照

  • 什么是架构
  • 核心概念
  • 常见误区
  • 小结与练习
  • 名词解释

可复现的最小实现

先把决策记录写成机器可读结构:

{
  "unit": "什么是架构",
  "inputFrozen": true,
  "scenario": "normal | boundary | single-fault",
  "firstDivergence": null,
  "cleanupRequired": true
}

再用同一条执行链处理三类样本:

type Evidence = { stage: string; expected: string; actual: string };
 
function verify(sample: unknown, expected: readonly Evidence[]) {
  const trace = runFromCleanState(sample);
  return expected.find((item, index) => trace[index]?.actual !== item.expected);
}

最后保存回归门禁,禁止失败样本静默通过:

normal      -> complete, invariant preserved
boundary    -> complete or explicit rejection
singleFault -> stop at first divergence, no stale output

用统一评分解释实验结果:

Q=Ccorrect+Ctrace+CrecoverRresidualQ = C_{correct} + C_{trace} + C_{recover} - R_{residual} Ccoverage=NverifiedNofficialC_{coverage} = \frac{N_{verified}}{N_{official}} Rresidual=P(failure)×I(impact)R_{residual} = P(failure) \times I(impact) Accept=(Ccoverage0.90)(RresidualRbudget)Accept = (C_{coverage} \ge 0.90) \land (R_{residual} \le R_{budget})

本章回顾

  • 什么是架构必须绑定冻结输入和明确成功标准。
  • 核心概念必须能画成结构并沿边追踪责任。
  • 常见误区要由正常、边界和单故障样本共同验证。
  • 小结与练习必须保存第一处偏离和清理重建步骤。
  • 名词解释决定方案是否可以进入下一阶段。

术语表

什么是架构

架构这个词被用得太滥,以至于有必要先把它讲准。是那些「昂贵且难以更改」的决策集合——选哪种通信协议、把系统切成哪几个子系统、依赖方向朝哪边指。它不是某段代码长什么样,而是这些代码被组织成什么形状。

架构 vs 设计设计解决「怎么实现」,架构解决「系统分成哪几块」设计怎么实现?类与接口字段、方法、继承关系函数与算法逻辑流程、复杂度模块与包代码组织、可见性设计模式局部问题的复用方案架构系统分成哪几块?系统边界内外边界在哪里划依赖方向组件之间谁依赖谁组件关系通信方式与契约架构风格分层、六边形、微服务进阶从局部实现决策上升到系统级结构决策
设计关注类、函数、模块级别的「怎么实现」;架构关注系统级别的边界、依赖方向、组件关系——从设计到架构是一次视角的进阶。

架构与设计的分界线不在「高层 vs 低层」,而在「影响范围」。架构决策是系统级的:一旦定下「前端调后端、后端调数据库」这条依赖链,它就约束了成百上千个模块的协作方式。而设计决策是模块级的:某个类用策略模式还是工厂模式,只影响这一个模块内部。换掉一个设计模式只需重构一个文件;换掉一条架构依赖方向,则要撬动整个系统。

核心概念

架构真正关注三件事:边界、依赖、组件关系。回答「在哪里切开」——把容易变动的部分和稳定的部分隔开,让前者的变化不传染后者。依赖回答「谁指向谁」——稳定的业务核心被依赖,易变的技术细节去依赖别人。组件关系回答「切开的各部分如何协作」——跨边界通信用什么方式,是直接调用还是通过接口。

之所以难以修改,正因为它是系统级的。一条依赖方向一旦定错,纠正它意味着同时改动上下游所有遵守旧方向的代码——这种「牵一发动全身」正是架构与设计的根本差别。架构师的角色因此不是画图者,而是决策者:他的核心产出不是 UML 图,而是这些「一旦定下就难以反悔」的取舍。

常见误区

小结与练习

  • 架构 = 系统级的高层结构决策集合,是「昂贵且难以更改」的决策,不是某段代码的写法
  • 架构与设计的分界在影响范围:架构系统级、难改;设计模块级、可局部重构
  • 架构关注三件事:边界(在哪切)、依赖(谁指向谁)、组件关系(如何协作)
  • 架构师是决策者与守护者,不是画图者;产出是决策及其持续守护

名词解释

讨论

评论区加载中…