《我的架构思想：基本模型、理论与原则》编二——架构原则，技艺、艺术与美

架构原则

架构第一原则：架构面向问题，但满足需求

“我们已接受的许多东西是有着商业背景的”

“面向需求通常是不考虑系统的背景的”

从提供方来考虑的方案，通常是面向“同类系统的同类需求”的。这种需求上的相似性才决定了方案的价值。它并不考虑确定系统的背景，因为背景的不同正好削弱了方案的价值。然而，我们事实上是无法脱离背景来讨论系统问题的。

“面向问题首先是客户视角的变化”

“面向需求”本身是没什么错的，因为我们的软件开发活动最终总是要解决用户的实际需求。但需求的“持续可变”是所有问题浮在冰海上的表象，正是它们随海水的、风力的变化而变化着，才导致我们“面向需求”去求解时疲于奔命。这其中，一个重要的问题在于：客户是很难从系统角度上识别问题的，并且当他们站在“客户与供应商”的层面上思考时，他们也完全不必要对可能的系统问题作出解释。

只有当二者站到“共同解决问题”的角度上来看，才是共赢的，进而问题本身就变成了焦点：需求可以通过对问题的阶段性关注、梳理来明确；需求的变化可以通过架构的确定性来消化。

对于“供应商/开发方”来说，面向问题会是一个主动发起合作，进而争取普遍合作的开端。

“面向问题与开发实作并无冲突”

但是“面向问题”这一概念对于开发人员同样显得空乏。因为问题的关键求解在于架构，而不在于具体实作阶段的某一个技术行为。

开发人员可以在任意时候、任意位置，就地实现数据库或数据结构。但是，这必将给架构角色带来层次规划上的灾难。因为如果推进这一方法，则在“第二阶段”来考虑数据建模时，系统架构将无法进行调整以容纳、应用新的数据模型。

因此，架构在第一阶段既不能“放任”开发人员的数据规划行为，也没有足够的信息与时间来进行数据建模。但这一矛盾的实质并不在于“谁做数据建模”，而在于“何时定义其细节”。而使架构角色在这里陷入了两难困境的原因则在于，他对自身的职责仍然缺乏必要的了解。回顾此前我们在架构过程中提及的两项架构责任：

  • 其一，架构对实施的约束；
  • 其二，架构的阶段抽象在实现域与交付域的映射。

由此看来，架构应当在第一阶段中与开发人员约定（注意做这些约定，其本质上也是数据建模活动）：

  • 开发人员的数据规划行为必须限于当前应用中的数据层；
  • 必须通过一个界面交付到应用层，避免直接访问；
  • 若该数据规划涉及多个应用，则必须由架构角色来确认规划的有效性；
  • 数据层的交付界面必须不涉及特定数据层实现方案的细节”

架构的约束既体现为对问题的把握，也体现为面向问题的、阶段性的隔离。它对整个系统工程构成影响的方式既包括一系列架构图例，也包括上述的一些实施规则，最后——也最为重要的是，还包括架构师对问题的分解。

“面向问题是架构活动的必须”

软件架构活动的来处并不在于“变化的需求”，只有将架构所解决的本质对象定义为“问题”，架构本身才有长期与持续性的需求；架构本身的复杂性与规模才有出处；架构应对于“持续可变的需求”才能寻得方法。

总的来说，需求可能一样，但问题却未必相同；需求可能被满足，但问题未必会因满足需求而消失；需求可能是破碎的，但问题却恒久而弥新。因此，架构的思维对象必须直接指向问题。唯只如此，架构活动的本质，才在于面向问题的求解；而其结果，才会是一个长期的、有效的、可持续推进的架构，而非应对一时之所需的技法。

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

“1. 形式化方法”

作为第一原则，“架构面向问题”是无助于讨论“架构是什么”这一设问的。架构作为一个确定的工作产物，它必须有对其形态的确切说明，否则我们无法以之作为后续实施的依据。

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

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

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

“2. 形式化的基础是抽象”

形式化方法本质上只是“在我们现在、在对思维的表达方式过于粗略的前提下的、不得已而为之的”一种方法。

其一，在表达之前的思维活动中，究竟形成了什么；其二，在表达之后的验证活动中，我们可选择何种方法。

确定的形式必然包括抽象、概念以及基于此的确定表达法。否则它必将无法作为我们表达确定思维的基础构件——与此相对应的，意象适合表达的是非确定的思维。
抽象是不具体的，但抽象的表达是确定的；具象是确实的，但基于具象的表达却是不确定的。如上二者互成矛盾，但是却构成我们思维与表达的全部极限。作为架构的目的——产生确定的系统——的所需，我们只能选择抽象。而所谓形式化，只是“思维的抽象表达”的一种方法。

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

架构存在的基本价值在于交流，如果不需要交流，那么这个开发活动中就自然不需要一个“具形的、存在的架构”。

总的来说，交流有两个基本的要素，其一是交流的主客体，其二是交流的对象。

任何有语法与语义并以语法为交流形式，以语义为交流对象的，都可以称为（广义上的）语言。

我们尽可以有任意多种形式，也包括这一形式的要件（我是指概念、抽象与表达法），但如果要表达架构师的思维，那么它还必须以语义为交流的对象。这是“架构师应以形式化语言为交流工具”的一个推理过程，在“形式化”上，它是指语言工具的基础要件；在“语言”上，它是强调语言的语义特性。

忽略语用”仍然是考虑“架构的目的——产生确定的系统”的所需，而进行的一个选择。

架构师所表达的系统是不确定的，在交流客体的感受上会变成“架构师主观而随意地阐述着系统。

架构第三原则：架构=范围+联接件。

“1. 基本前设”

(本原则是对第二原则的补充，讨论架构作为工作产物时的内容。)

架构的目标究竟是什么？我们当然知道其目标是系统——无论是大的、复杂的体系，还是一个小的、有含义的组成，又或是我们要考虑其系统性的任何东西。然而这一概念下的系统，其内涵是丰富以至于无可穷尽的。架构作为一个事实工具或对于这一系统的事实影射，只能表达其中的部分而决非全集。因此，我们所谓“架构的目标是什么”，其答案必将指向系统，也必然是系统特定的一面两面或数个方面。

“2. 范围与联接件之于系统的意义”

决策层在系统的方向问题上赋予架构师的职责是“目标的映射”。这包括两方面的含义，其一，不一定是确实的目标，例如某个产品或产品的某个版本；其二，是对目标的约束，而非说明其实施的细节。范围与联接件是架构师的两个工具，与其说它们是对规模与复杂性的求解，不如说它们事实上就是架构师对“系统的方向问题”的两个求解。

所谓方向与目标有一些基本性质，包括：其一，系统的方向可能是确实的，也可能是阶段性变化的；其二，阶段目标清晰而明确，但方向却可能存有模糊性；其三，方向必是一个面的问题，而目标方才是点的问题。

我们在层次架构中通过“逐层清晰”来解构系统复杂性一样，这一手法通常用来确保系统长期的不变性——复杂性通常是由可变性引起的。

架构在应对系统方向下的规模问题时，采用的方法通常有两个：其一是对“系统组成”的明确约定，例如模块图或（细化的）层次架构图；其二是对系统构件的明确概念。后者——构建明确概念是架构抽象中最困难而又最重要的工作之一。

系统总在变大，在它的形态与内涵两个方面都必将存在失控的风险。这两个风险是骈生的。此外，风险与机会也是骈生的，所以架构不仅能够反映系统的“范围与联接件”，也可以反映系统的“转折点”。只是后者常常仅被视作风险而遭到严防死守罢了。

架构第四原则：过程之于结果，并没有必然性。

“1. 基本前设”

所谓工程，是一个实作问题，简而言之，工程讨论的就是如何把东西做出来。在这个问题上，架构工程与软件工程类似，也是可以追溯到“过程、方法、工具”三个要素的。其中，架构第二原则主要讨论的是方法论问题，间或讨论到与方法论适配的工具问题；架构第三原则可以视为对工程产物的补充。

形成论与组成论是两个过程观点，前者是过程论的动态模型，后者则是静态模型。将架构结果作为工程产物时，静态模型强调架构的构件之间的结构关系，以及通过这些结构关系来维护“架构目标的系统性”的方法；动态模型则强调架构是一个与时间相关的产生过程 13，在时间轴以及组织性上，架构团队以及系统的参与者都是变化的，（整体来看，）其结果在形态上也是变化的。在后者——形成论的视角下，架构结果是可以通过阶段进化来获得的，而至于这一产生过程是否是一次性的或迭代数次的，则是过程实施中的选择。

“2. 有关过程正确与结果正确的讨论”

“正确的步骤会产生正确的结果”是丰田模式的核心原则的重要组成部分。

生产过程中如果包含大量的修正过程，则其效率会变得相当低下。这是因为修正过程将使生产过程的周期变长且导致产品品质下降，这些都可以理解为是由过程的不确定性导致。因此，总的来说，尽量摒除生产过程中的修正是得到“正确的步骤”的必经之路。为了这一目标，传统的生产型企业都会有所谓的“产品研制”阶段，在这个阶段中允许大量的修正，并最终交付一个可投入生产的“正确的步骤”。“生产”作为一种工程手段，大抵上是从一个“正确的步骤”的交付开始的。

形成论下的架构产出是过程记录而非指导性规范，但这是出于“能力上无法做到规格化”，还是出于“架构的某些特殊性质决定了它无法被规格化”，是我仍存疑的；其二，软件系统产品通常是一次性产生的，因此它是否需要一个生产过程并将架构作为生产阶段来理解，是我存疑的；其三，即使上述两点均成立，即我们确需“基于架构的生产过程，且架构规格可作为指导性规范”，我对其可实施性（综合考虑实施成本与团队成本）也是存疑的。
但是形成论的“映射与约束”性质必将由组成论来实现。因此结合组成论与形成论，可以在一定程度上解决上面的问题。

我们尚未能找到过程正确性之于结果的必然关系，因此“正确形成+正确组成”并不等于正确的架构。

架构第五原则：系统的本质，即是架构的本质。

“1. 普遍性架构原则的提出”

架构是面向问题的求解”也只是一个结果，而非完整的、准确的、概念上的架构的本义。

我们必须重新定义我们所讨论的架构、系统以及二者的关系，这是上述架构第一和第二原则作为普遍性架构原则的必要前提。

“2. 系统性”

总的来说，形成论与组成论是“（面向实作问题的）过程论”下的视角。我们不能因“过程是这样需要的”，而反过来指称“一个系统的本质为何”。本质是不应随应用的需求而变化的，否则其必然是一个“可用的观察”，而非本质本身。

我们之所以将某个领域集或其他类似的“组成/构成/集/……”称为系统，必是因为它们之间存在某种系统性，以维持它们的内部关系与外部表现。

这种系统性是系统存在的唯一依据、核心矛盾与主体价值。既如此，这种系统性也必是架构——系统所有的可能映像——的基本事实、本质问题与形成驱动。

唯有将系统的本质与架构的本质都设定为对“系统何以为系统”的拷问，才能抹去二者因概念抽象而导致的差异。唯只如此，它们才能在“问题与解”上真实地一致，才能在“过程与方法”上无视于系统与架构的先后问题。

“3. 本质”

“在本质上相同的抽象系统，其系统解集的抽象也是本质上相同的。”

综观我们的知识构成，我们所见并能自由论及的一切系统，都是事实系统的抽象系统，我们只是在多个抽象系统中维持着本质上的相同。
系统的本质即是架构的本质。我们必将二者的本质指向同一，其复杂性，亦即结构的本质，方可同一；其方向性，亦即目标的本质，方可同一；其系统性，亦即问题的本质，方可同一。

技艺、艺术与美

架构可以“学而时习”的部分

就传授来说，授业者可以分解步骤、讲述原理并总结经验与诀窍；求学者可以亦步亦趋地跟随，先得其形实，再究其质底。就实作而言，实作者可以在技术的实践活动中有所变化，若这种变化是有了质的区别，我们就称之为“新技术”了。但即使新旧技术存在质的区别，其目的却没有变化：实现相同的目标，或解决一样的问题。

架构的确首先是一种实作的技术。这是毋庸置疑的，因为的确是在工程实践过程中产生了架构这一角色并承载了属于它的需求。这也是架构过程的“形成论与组成论”两个观点的真正出处。对于一个既存的架构，实作者认为它是源自于一个形成的过程，所以得到前一种观点，即架构的出处在于这些阶段的组合；而当实作者认为架构表达的是系统映像的具体内容时，便会得到后一种观点，即架构的落足在于这些内容的组成。
无论是前者亦或后者，都是将架构作为一个死物，并试图通过模仿来复制一个新的架构。

死过程与活灵魂

即使你做出来的同样是一个三层（或 N 层）架构，如果你是通过系统分析、思考、权衡而得到这一架构决策的，那么它仍具有独特而丰富的架构思想；但如果只是因为与当前系统的背景类似，而使得你选择了这种架构形式，那么这只是一个工程师的技术选型，而非架构师的架构过程。

架构思想是认识系统的方法与结果：从方法上来说，思想决定了如何认识系统；从结果上来说，思想表现为对系统的认识。

“窠臼是思想的表达，形式是架构的道具。”

美

关于技术、技艺与艺术，有三种美。其重点各有不同。

  • 首先，技术的美在于可行。
  • 其次，技艺的美在于超越。
  • 第三，艺术的美在于如一。

若架构师确有思想，但无法表达出来或他的表达与思想并不一致，那么是不美的；若架构师拿出了一个“看似完美”的作品，却没有任何有意义的思想，那么也是不美的。若架构是一门艺术，则架构艺术的美，必以追求思想、形式、技艺完美如一为最终标准。

架构的美

美的学问究其根底是讨论三类东西：美，美的对象，以及美的感受与意识。

从架构对于工程的意义、对于系统的意义以及对于一个实施团队的意义来说，无限制的、漫无目的地追求美是一种浪费。

架构的美的对象定位于“时间与空间”两个维度。在时间维度上，我希望一个架构的美在于能以其持续性来保障系统的实施；在空间维度上，我希望一个架构的美在于能以其结构性来保障系统的成本。无论是软件产品还是硬件产品，对于这样一个系统，若既是可实施的又是成本可控的，或称为规模与复杂性可控的，那么该系统是否能最终完成便只需由必要性来决定了。

当我们回到美的对象，亦即时间与空间下的架构，亦即探求其持续与结构上的美的问题时，我想尽我所能使用的词汇，尽我所能表达的认识，尽我所愿意接受的、对美的架构的最终审美标准来说

“架构的美在于不朽”

舞者

通常，面对一个系统，一开始就讨论高并发、大流量、大数据以及大规模运算的架构师，是入门零段的。他还不懂得忽略与聚焦。

通常，面对一个系统的组成，大谈平衡与模型的架构师，是入门一段的。他还不懂得平衡只是技法，系统是没有平衡的，系统是在动态中不平衡地发展的；系统是一个时间轴上的东西，而非一个瞬间的衡态，例如模型。

通常，脱离了平衡的味趣，奔逐于系统的关键，寻求种种方案并努力实施的，是架构师的初段。这并没有不好，这些架构推进并演义了整个行业的瑰丽，如同那珠宝闪烁，成就了前台的舞者。

通常，诠释着舞蹈之绝美的有两种人，一种是会审美的看客，一种是会创造美的编舞。他们都将自我之见作用于美的一片一片，如同架构师通过时间与空间的拼接来完成系统的全体。美与不美都任由评说，而又各有评说的标准。无论是作为看客还是编舞，这样的架构师已得架构之纲法精要。

通常，把舞蹈表现得完美无缺的，是一个舞者。那个舞者就是那段舞，当他表演的时候，编舞认为这段舞蹈是为舞者而生，而自己只是那个接生者；看客认为自己是舞者；舞者却从不承认这是表演。这样的架构师，他的架构对象和自己已成一体，但我很难找到一个人来诠释这一角色，因为他必已完美地谢幕。

其作品也必为不朽。

*附

《大道至简》这本书通过“工程层状模型”（EHM），从“实现者”这一角色出发，并论及 “团队”和“经营”角色。但是——如同上面的问题一样，EHM 模型将这些角色析别出来的时候，也少了一半的观察。

p-31

在使用“在哪里？是谁？在做什么？”这一工具来仔细分析这两类角色时，我们会发现他们所在的领域也是有区别的：实现角色是在技术领域，团队角色则是在工程领域。技术领域关注的是实现的细节，即通过何种方法能将目标有效地实现出来，因而会追求这一实现过程的最优解；工程领域关注的是团队及其所应对目标的规模，在大多数的情况下，这一角色期望控制这一规模以使“目标、资源与质量”可按某种预期、整体地得到保障。有趣的是，从技术领域来说，一旦更细节的或者更宏大的实现成为可能，那么他们将毫不犹豫地将这种“可能”升级为“必须”，并为之充满激情；而这一切，往往又是以牺牲规模为代价的。