.. Kenneth Lee 版权所有 2024
:Authors: Kenneth Lee :Version: 0.1 :Date: 2024-01-17 :Status: Draft
为什么不要画市场式的架构图
作为一个信息领域的工作者，我对“传递了什么”这个主体颇为敏感，在一般人的交流中， 不容易区分“他称赞人”和“他说‘你很英俊’”，但对于负责保存，传递，展现这个信息的我 来说，这根本是两个东西。
所以，你画不同的系统架构图，也许你觉得你描述的是同一个系统，但我看到的就不一样。 概念视图，部署视图，开发视图，描述的都是同一个东西，但从信息传递的角度，我看到 的就是完全不一样的东西。
所以为什么这些视图叫做架构？你可以类比一个房子：建好使用的整个房子包含无数的细 节，但我们单独谈“它什么能立住”？和受力有关的信息是哪些？这就是这个房子的架子， 这就是架构。同样的，为什么所有地方都能供电？为什么污水能流出房子？这些每个独立 的视图，就是一个“架构”。全部信息都堆上来，你看不见架构，架构就是单独被提取出来， 我们可以进行权衡的东西。
所以，那种市场常用的，用几个框框分出几个部分，然后在里面填上各种关键字的图，那 不是我们开发意义上的视图。那些只是一些牛逼词语的提词器，它不构成一个可以权衡， 可以判断的逻辑，那和“架构”离得很远。
所以架构讲究逻辑推理，如果你房子建好了，也不打算改了，住就住了呗，这不需要分析 什么架构了。架构要不就是我还没有整个房子，我要决定所有的其他东西（泥水，水电， 打墙……）怎么组合的问题。要不我打算改这个房子，我也得决定改的时候怎么保证原来的 组合不会被破坏了的问题。无论是哪种情况，你做“架构”，都是面对一个未来。所以不要 装作你多务实，非要说些“和现实绝对一样”的东西。和现实“绝对一样”的通常都是废话。
所以，你要表达你解决一个平台多个使用者的问题，你就单独建模使用者有什么共同的需 求，平台代理了它们哪部分的能力，又如何管理它们的差异。这个描述也许也呈现为一个 类图，但带着这个目标，你要表达的逻辑就不仅仅是那个类图。这个类图才会构成架构， 否则它仅仅是圈圈而已。
同样的，如果你要表达“我用了一种更好的版本管理方式”，你就不要建模你有这个模块那 个模块，画出那种“绝对正确”的市场框框图。然后随口补两句，说你用了两个版本很好。 你要表达你的版本管理方式好，要定义概念空间，把“问题凸显”出来，说清楚如果不管这 件事，哪里会出问题，然后用版本来表达你可以为什么可以把冲突的需求隔离开。
我们现在的问题是，一说架构就画圈圈，堆一堆名词。把谈架构谈成了仪式，就没打算传 递什么信息，这样就不是在谈架构。