Question

1. 形式化方法

作为第一原则，“架构面向问题”是无助于讨论“架构是什么”这一设问的。架构作为一个确定的工作产物，它必须有对其形态的确切说明，否则我们无法以之作为后续实施的依据。举例来说，若“架构师所想”是架构，那么架构的本意是无形的，它在被叙述的一刹那便已走了模样；若“架构师所言”是架构，那么架构最终必以录音为载体，并且后续的分析也将基于对录音的讨论。类似的，我们讨论架构的形态，是要讨论架构本身可否用作持续依赖（我的意思是实施）和持续讨论（我的意思是不同阶段的架构），并更具体地阐明“依赖与讨论”的可行方法。

不幸的是，总体来说，在这个问题上我们的可选答案并不多。就目前对思维表达方法的研究来看，我们只有意象化和形式化两条路可走。意象化包含联想与想象，例如说作者 A 在纸上画下一个圆，观者 B 可以自由地认为那是一张面饼，或者是昨晚所见的月亮。至于这一意象是否确实是 A 所绘的这个圆的本意，是不要紧的。如果非得说这一意象有传递的效果，那么我们可以强调 A 绘制的圆表达了“完整”，而 B 所见的面饼与月亮总的来说在形态上也是完整而无有或缺的。

自然语言确实是形式化的，例如我们可以强调主谓宾这样的结构。如果言者 A 在表达的时候只满足了谓宾结构，我们还可以进一步地细化规则，来讨论“主语”在语法上的承前省略和蒙后省略等问题。但总的来说，自然语言一方面是形式化的，另一方面确实有着相当的随意性 3 。例如，我们在此前讨论过的“两岸猿声啼不住”，其猿声是否出自真猿的问题，这一问题在自然语言的形式化语境下就是无解的。

从非形式化到形式化，一路走来，我们唯一可选的是“更加明确的形式化”。这是表达架构——这一思维活动的结果的最终方法。

2. 形式化的基础是抽象

但是形式化本身只是一个方法，我们不能说“用包饺子的方法包出来的就一定是饺子”，这是方法之于事实的区别。我们必须将“架构是什么”最终确指到事实，而不是简单地定义它的实现方法——我们必须时时反省：形式化方法本质上只是“在我们现在、在对思维的表达方式过于粗略的前提下的、不得已而为之的”一种方法 4 。

形式化到底要表达什么？是什么决定了形式化作为一种方法的有效性？回顾这两个问题，其核心在于：其一，在表达之前的思维活动中，究竟形成了什么；其二，在表达之后的验证活动中，我们可选择何种方法。前者必当我们于头脑中形成一个确定的事物，才能将其形式化地表达出来。这一事物，必是抽象的，而非具象的。关于抽象与具象的问题，我们已经反复论述过了。这里只强调一点，具象是可以表达的，例如图画或雕塑，乃至于音乐；但具象的表达是基于感官上的一致性的，而非基于——像抽象那样——在概念上的一致性的。为了说明这一细微措辞上的区别，我们可以假定回到原始社会中，原始人 A 向 B 举出一根树枝，假设他要表达的是昨天他所见的另一根树枝，那么这是具象的，二者不同一但是等义；若他要表达的是“1”个某种东西，那么这是抽象的，二者——一根树枝的“1”，与一个某种东西的“1”——是同一且等义的。

抽象的问题在于“1”必须是原始人 A 和 B 都能共同接受的一个概念。若这个概念原本不存在，或无法通过其他概念或方法予以传送，那么 B 将无法理解 A 的这一形式化的含义。这也是佛陀拈花无解的原因，因为这一形式不存在任何概念，也不存在让弟子们理解这一形式的、其他的概念基础。

确定的形式必然包括抽象、概念以及基于此的确定表达法。否则它必将无法作为我们表达确定思维的基础构件——与此相对应的，意象适合表达的是非确定的思维。我们希望构建“系统”，并对该系统作出引导它中长期发展的“架构”，因此这一思维的结果应作为一个确定抽象，并以确定概念来陈述。若是不确定的，那么我们无法正确表达给原始人 B——当然，也无法表达给某个程序员。

抽象是不具体的，但抽象的表达是确定的；具象是确实的，但基于具象的表达却是不确定的。如上二者互成矛盾，但是却构成我们思维与表达的全部极限。作为架构的目的——产生确定的系统——的所需，我们只能选择抽象。而所谓形式化，只是“思维的抽象表达”的一种方法 5 。

3. 形式化的表达必须以语法和语义为基础，而忽略语用

架构存在的基本价值在于交流，如果不需要交流（例如只有一个开发人员的个体工程，且该开发人员总能自始至终地 6 明确“在做的软件”与“事实的系统”之间的映射关系），那么这个开发活动中就自然不需要一个“具形的、存在的架构”。

总的来说，交流有两个基本的要素，其一是交流的主客体 7 ，其二是交流的对象。例如，我们说“世界各国的经济文化交流”，那么总是包含上述两个要素的，其中的交流对象就是“经济文化”。又例如，我们说“集装箱促进了全球货物的交流”，那么对象就是“货物”。问题在于，这一类的“交流的对象”总是确实之物——无论是虚的经济文化还是实的货物，那么它需要的是一个载体。然而，另一类的交流所指的对象却并非“某物”，而是“某物的含义”，这种情况下，我们的可选工具——而非简单含义上的载体——只剩下了语言。这里说“只剩下”，是因为在我们人类的抽象概念中，只有语言既包括语法又包括语义，并且使用的是语法来交流，而“交流的对象”却是其语义。

任何有语法与语义并以语法为交流形式，以语义为交流对象的，都可以称为（广义上的）语言。举例来说，眼神交流是伴随着形式的，我们所谓的眼神不单单是指瞳仁，还有瞳孔的大小以及眼皮的张开程度等——若抛弃这些，我们是达不成眼神交流的。但就眼神的形式而言，瞳仁发红是病症，瞳孔发散是死相，眼皮张开那是醒着。这些形式若不包括某种语义——我的意思是愤怒——那么它只能表达一种医学的或生理学上的现象而已。

所以若将眼神视为语言交流，也必是有语法和语义的，而且必然表达为语义的交流——后者才是它作为语言这一概念的充要条件。再回到我们的形式化的问题上来，我们尽可以有任意多种形式，也包括这一形式的要件（我是指概念、抽象与表达法），但如果要表达架构师的思维，那么它还必须以语义为交流的对象。这是“架构师应以形式化语言为交流工具”的一个推理过程，在“形式化”上，它是指语言工具的基础要件；在“语言”上，它是强调语言的语义特性。

“忽略语用”仍然是考虑“架构的目的——产生确定的系统”的所需，而进行的一个选择。这一选择事实上仍有争议。比如说，架构师确实会在实施中将一幅架构图用于不同环境下、应对于不同对象的解释。就语言上来理解，该架构图表达的语义便因语用（该语言的用所）的不同而不同。但这带来了一个问题，也就是：架构师所表达的系统是不确定的，在交流客体的感受上会变成“架构师主观而随意地阐述着系统”。

所以忽略语用是一种选择而非一种必需。基本上来说，如果 A 与 B 有足够的、相当的架构能力——因此他们能基于相同的背景做出相同的理解，那么二者之间仍然可以随时切换着语用环境来交流“同一幅架构图的不同含义” 8 。但如果将这一行为扩散到整个项目团队，那么既是不公平的，也是不可取的。