笔记 · 67 | 架构思维篇：回顾与总结

本篇要回答的问题：第五章"架构思维篇"到底讲了什么？把"架构之道、业务的正交分解、领域理解"这三条主线串起来，架构师该如何掌控全局？

本讲是第五章的回顾与总结。前面几章已铺好信息技术的"骨架"，本章把焦点收到不变的思维内核上。许式伟用三条主线收束整章：架构之道（虚实结合 + 心性修炼）、业务的正交分解（一切架构动作的基础）、领域理解（最难的部分，也是讲半部信息科技演进史的原因）。

架构之道

架构思维篇内容结构图

理想场景是从干净的需求文档出发做需求分析→概要设计→详细设计→编码；现实却是拿到一堆源代码 + 少得可怜的过时文档，被安排加功能或改顽固 Bug。

架构设计，设计为先，架构为魂——用架构的系统化、全局性思维来做设计。

关键判断：架构之道是虚实结合之道。架构思维不能只靠熟读理论（否则架构师早满天飞了）。若两者只能取其一，选实践。 从实悟虚、从虚就实，在不断实践中升华认知。

架构课前四章构成信息技术主体骨架：

侧重点放在架构演变的过程（研究什么在迭代），所以学的不是静态骨架，而是有过去与未来的"真真正正的全貌"。架构师能力与心性：

维度	能力项
技能	理需求的能力、读代码的能力、抽象系统的能力
心性（更根本）	同理心（认同他人）、全局观（好奇心+学习韧性）、迭代能力（反思、在自我否定中成长）

架构就是业务的正交分解。每个模块都有它自己的业务。 这里"模块"泛指函数、类、接口、包、子系统、网络服务、桌面程序等。

要点	说明
接口是模块边界	接口是业务的抽象，也是与使用方的耦合方式；要反复审视、去掉"过度/多余"的约束
三步曲	需求分析→概要设计→详细设计，都直指正交分解，从模糊到精确无歧义
两大难题	需求的交织（全局性功能）、需求的易变（场景发散）
架构师的信仰	任何功能都可正交分解，分解不出只因还没透彻理解需求

业务分解 = 最小化核心系统 + 多个正交周边系统。核心一定最小化、要稳定，坚持不往核心加新功能，业务架构就不会有臭味。伤害值经验公式：

对每一处修改 ∑ log₂(修改行数 + 1)。同一周边功能相邻代码算一处，不同周边功能哪怕相邻也算多处。修改处数越多，伤害越大；鼓励每处尽量只改一行，更多代码放周边模块。

OCP 两层含义（架构课的灵魂）：① 模块业务"只读"，要变就归档放弃——软件可"搭积木"搭出来，关键是形成更多"业务只读、接口稳定、易组合"的积木（“每一个模块都应该是可完成的”）；② 变化点用回调/接口（简单）或插件机制（复杂）开放出去。

关键判断：理解"核心系统+正交周边"还不足以根本改变架构能力，最难的是领域理解，所以需求分析很关键、也最难讲透。本课用的是"笨方法"——把信息科技演进史讲一遍。

为什么说只讲了"半部"演进史：

阶段	别称	本质
程序驱动	IT	自动化的极致；软件让自动化成为普惠价值（上半部演进史的核心收益）
数据驱动	DT / 智能时代	数据科技；不只是深度学习/机器视觉那么片面

本课把话题收敛在"如何把软件跑起来并保证持续健康运行"。完整的数据治理与业务运营体系是另一本书的主题（作者的另一心愿）。

整章用三条主线收束：架构之道（虚实结合、心性修炼），业务的正交分解（最小核心 + 正交周边 + OCP + 伤害值），领域理解（最难，靠讲半部信息科技演进史来补）。理解了本章就有了构建高可扩展架构的基本认知，但不要停在认知上，要多实践——架构功夫全在平常，不要轻率做全局性重构。

架构思维篇三主线：虚实结合的架构之道（取实践）、业务的正交分解（最小核心+正交周边+OCP+伤害值）、最难的领域理解（靠半部信息科技演进史补）——认知之外，更要平常实践。

把"架构就是业务的正交分解"当作信仰：你当前系统里，是否有一个你一直觉得"分不开"的功能？按作者的信仰，那只是因为你还没透彻理解它的需求——试着说清楚，它到底卡在哪个还没想透的需求点上？