架构第二原则：架构基于概念抽象，而非想象

架构作为一个确定的工作产物，必须有对其形态的确切说明，否则无法作为后续实施的依据——若”架构师所想”就是架构，那么架构本质是无形的，被叙述的一刹那就已经走样。表达思维只有两条路：意象化（联想与想象，如一个圆可以被自由解读为面饼或月亮，传递的效果不依赖于作者的本意）与形式化（越来越明确的规则化表达）。形式化本身只是一种方法，不能等同于事实——它真正要表达的是”思维活动中形成了什么”，而这个”什么”必须是抽象的而非具象的：具象的表达基于感官上的一致性（一根树枝可以指代另一根具体的树枝），抽象的表达基于概念上的一致性（一根树枝的”1”与一个苹果的”1”是同一概念）；抽象要成立，前提是这个概念本身能被双方共同接受，这正是”佛陀拈花”式沟通无解的原因——不存在可传递的概念基础。既然架构的目的是产生确定的系统，就只能选择抽象概念作为思维的载体，形式化不过是”思维的抽象表达”的一种具体方法。进一步，形式化的表达必须以语法和语义为基础：交流的对象是语义，语法只是交流的形式载体，只有同时具备语法与语义、并以语法为交流形式的才能称为（广义的）语言。至于”语用”（同一份表达在不同场景下被赋予不同解释），书中主张有意忽略它——因为架构的目的是产生确定的系统，若允许语用自由切换，架构师对系统的表达就会变得主观随意；但这只在架构师团队具有相当且相同的背景能力时才可行，扩散到整个项目团队则既不公平也不可取。

结构图：

flowchart TB
  Q["表达思维的两条路"]
  Q --> I["意象化<br/>(联想/想象,效果不依赖本意)"]
  Q --> F["形式化<br/>(越来越明确的规则化表达)"]
  F --> C["前提:必须基于抽象概念<br/>(具象靠感官一致,抽象靠概念一致)"]
  C --> L["以语法为交流形式<br/>以语义为交流对象=(广义的)语言"]
  L --> U["忽略语用<br/>(为保证系统表达的确定性,<br/>仅在团队背景相当时可行)"]