Question

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

我们一贯地认为“架构是对系统的映射”，因为若非如此，我们便不需要架构。架构行为的目的就是要得到这一映像，至于其后续是基于该映像来讨论、重构或是实作，都是一个次要的、操作性的问题而非架构行为本身的目的。从这一点来说，“架构是面向问题的求解”也只是一个结果，而非完整的、准确的、概念上的架构的本义。

我们一再论及，架构只是系统一个侧面的映像；并且，我们将架构思想指向“面向系统的问题”，才进一步地确定了“（我们所讨论的）架构”是系统的哪一个方面的映像。那么，架构第一与第二原则事实上只在讨论一个狭义的架构，是“解决系统确指问题的一种架构思想与架构方法”。由此得出的推论是：我们一直在努力追寻的仍然只是系统的一个面。“架构”这一抽象在我们此前的讨论中仍是相对狭义的。举例来说，我们讨论过的“过河问题”中，若问题是“过河”，那么它的解就是“过河的架构”，其后续自然也就是做船，或者趟过去，或者游过去。总而言之，问题确定了，其解也就不言而喻。

这一误区的起源是第一和第二原则中的两个原始设定 18 ：

• 其一，架构是系统的侧象，这是就其“表象”的表达。但是，这意味着它只是架构的自我释义，是“我之我见”，作为推论系统的事实孤证是存疑的。
• 其二，架构映射系统，这意味着系统先于架构而既存。但是，系统也许原本是不存在的。例如，问题是在某种背景下既存的——假设我们对问题背景缺乏足够的认识，因而这一背景尚未系统化——那么若基于“架构映射系统”这一观点，也就意味着我们无法进行任何有意义的架构工作。

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

2. 系统性

我们已经提到过“（架构在）时间上的可持续性”，并进而提出形成论所讨论的两个问题，其一是规模，其二是通过组织过程来实现规模。但这个“可持续性”究竟是系统自身的本质问题，还是因为形成论的“所需”而带来的设问，也是“我之我见”的孤证。类似地，在组成论的视角上，我们也主要讨论了复杂性的问题。其中，在层次化的结构模型中，我们事实上是讨论了其中的一个解集，即“通过隔离可变性来解构复杂性”。

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

那么，到底什么才是“系统的本质问题”呢？

我想我能对这一问题提出的唯一可能的答案是“系统何以为系统”。也就是说，我们之所以将某个领域集或其他类似的“组成/构成/集/……”称为系统，必是因为它们之间存在某种系统性，以维持它们的内部关系与外部表现。这种系统性是系统存在的唯一依据、核心矛盾与主体价值。既如此，这种系统性也必是架构——系统所有的可能映像——的基本事实、本质问题与形成驱动 19 。

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

3. 本质

我们知道，我们之所以用“语言”来指代那些程序代码，是因为它们是我们与计算机交流的工具，这与我们的自然语言——在作为交流工具上的——本质是相同的。我们也知道，计算机作为物理机器能够产生运算效果是因为开关状态与二进制——在作为算数工具上的——本质是相同的。

我们已经提及过类似这一切的、最关键的、背后的假设：

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

综观我们的知识构成，我们所见并能自由论及的一切系统，都是事实系统的抽象系统 20 ，我们只是在多个抽象系统中维持着本质上的相同。无论“问题的背景”是或不是一个既存的系统，我们的架构与这个“即将被识出的系统”其实都必将是两个“本质相同的抽象系统”。因此通过架构行为以得出一个系统，与通过一个既有系统得出它的架构，在认识论的视角下是完全无二的。

系统的本质即是架构的本质。我们必将二者的本质指向同一，其复杂性，亦即结构的本质，方可同一；其方向性，亦即目标的本质，方可同一；其系统性，亦即问题的本质，方可同一。

1. 这里的意思是说，是否使用内存数据库，或者某种特定的数据结构（可以考虑结构化文件存储），或者特定的本地数据库等，这些方案的选择是由开发人员来决定的。 ↩
2. 这里涉及两点，其一是所谓“特定……实现方案”，例如交付界面不能是“对于 a 用户，存取 personal.dat 文件以得到 user 数据结构中的 age 成员”，应当抽象为“对于用户名 a，存取 user 数据项（或 age 值）”；其二，这也意味着要求这样的开发人员有一定的系统设计能力。 ↩
3. 这一观点事实上是对“自然语言是否是形式化的”的一个拷问。一定程度上来说，自然语言中“被形式化”的部分是我们对语言的形成及表达的阶段求解，而其他的则是我们尚显无知的部分。 ↩
4. 事实上我已经想到了某种不以形式化为方式的表达，只是它并不适宜于我们这里讨论——不过即使如此，它与“架构基于概念抽象”仍然是不悖的。 ↩
5. “形式化系统总是按如下顺序形成的：先确定有意义的符号，然后从符号中抽象掉意义，并用形式化方法构成系统，最后对这个所构成的系统作一种新的诠释。”这是著名哲学家与逻辑史学家波亨斯基（J.M.Bochenski）在《当代思维方法》中对形式化的方法的概括。 ↩
6. 我的意思是说，即使是同一个开发人员，他也必然面临“现在的系统”与“以前的系统”之间的差异。这种差异的表现手法之一是版本化的源代码，之二则是不同阶段的“架构”。就其实效性来说，后者在讨论“整体差异”方面是更有优势的。 ↩
7. 如果是一个人自言自语，是我之我的交流；如果是自我的反省，是我之于故我的交流；如果是我的畅想，是我之于势我的交流（此势者，至而未至也）。总而言之，交流总是有主客体的，无论是彼此之别，或一己之侧相。 ↩
8. 这并非不存在，例如在架构师团队中基于“体系架构”来讨论部署就是常见的事情。问题在于这一讨论中的信息——抽象对象及其概念——过于粗略，难于实际地指导部署过程，因此也就不能取代“部署架构”来与部署人员交流。 ↩
9. 因此我并不能确切地说“世界上所有称为架构的东西”都适于本书的讨论。 ↩
10. 在实践中，我通常会要求架构师试图站在两个点上考虑系统脉络，一是核心数据的流向，二是用户行为的起始。这许多时候决定了整个系统中的、相对长期不变的东西。 ↩
11. 在实践中，我通常会要求架构师以“一句话或一个标题”来定义他的系统。我们最终必须关注这句话或这个标题对于系统的概括力与约束性，而非去感觉它是否醒目或时髦——后者通常是产品经理的事情，并且常常为市场经理以及大老板所乐见。 ↩
12. 微之甚微，巨之愈巨，皆是系统规模的增加。 ↩
13. 注意，这里并没有用“生产过程”。在一定程序上来说，“生产”是有特定的工程含义的。 ↩
14. 引自《丰田汽车案例：精益制造的 14 项管理原则》，杰弗瑞•莱克著。 ↩
15. 然而我们现在的过程论者，常常会忽略了生产型企业中的“研制”过程，以及研制的本质是“通过大量的错误修正来得到正确的步骤”这一事实。 ↩
16. 可以理解为生产过程中，基于某个产品原型的具体生产工序。 ↩
17. 有两个原因，其一是目前的模型表达法没有参数化，其二是工序本身不是组成论视角下的结论。 ↩
18. 我们此前的绝大多数讨论都是基于这两个设定的。 ↩
19. 主体价值是形成系统的核心驱动力量，持续性、复杂性或可变性只是这一过程中的种种表现而已。 ↩
20. 在这样的系统中，是无法且不必讨论“佛陀拈花”这一问题的。 ↩