3.260. 视图和决策面

最近在评审一个架构设计的时候，又发明了一个新概念，叫“决策面”，本文细化这个概念。

被动写的架构设计很容易陷入一个陷阱，就是为写架构设计而写架构设计，而不是为了设计而做架构设计。

所谓“被动写”，常常出现在组织流程上要求写架构，或者学习写架构的人希望“正确地写架构设计”。我以前用“我没错”这个概念去解释这个问题：

但“我没错”是个反向的定义，只定义什么不对，但没有定义什么是对的。你不可能要求做架构设计的人主动做一个“有错”的设计对吧？但“对”的架构设计里面，我们还是可以发现很多例子，这些例子中，它的“设计逻辑”确实没有什么用，这是为什么呢？

真实的设计有非常多的细节，我们还是用简单的事情作为类比比较容易突出这个主题。比如说我们要过河，如果我们抱着行李直接下水，这就叫“没有架构设计”，因为我们没有一个总体的打算，下去随着水浅的地方走啊走，可能最后走回到同一侧的岸边去了，也可能走到水流湍急的地方直接被冲走了。

我们做架构设计，是为了在整体上分别处理我们的细节，这样我们成功的机会就变大了。比如我们看好中间有一个小岛，我们分两步走，第一步先到达那个小岛，第二步从小岛去对岸。我们觉得这个设计是必要的，因为没有这个设计，我们就会刚才提到的，走下去回到同一侧。这是我们引入架构设计的原因。

但如果你的架构设计要做样子，说我们需要先到一个小岛上，然后从小岛过去。但这个逻辑和是否能到对面没啥关系，这个设计就变成了做样子了：样子上，你和前面我们认为是架构设计的那个逻辑很像。但你能总体上解决能否过河这个问题。

请注意了，你说先去一个小岛，然后过河，这件事还真的可能和过河有点关系。但它不是一个完整的说明如何过河的逻辑。我们设计需要一个完整的逻辑，说明我们先去小岛，然后过河，确实是可以过河的。为了证明这一点，我们可能还有其他证据，比如去小岛和小岛去对岸，都是有浅水区可以淌的。在我们下水前，我们没有所有的细节，但我们必须有置信度，让我们放心敢选这个方向过河，这不是个事实的问题，而是个信心的问题。所以，它是一个抽象的东西。这个东西，我就称为“决策面”，一个决策面，是一个抽象，从我们认知的事实抽象，得出，XXXX方案是一个可行，接近最优的选择。所以，决策面是一个可以权衡和证明目标的“视图”，如果你的设计（呈现为一组Rule或者Constraint）不能构成这样一个决策面，它就是“正确”但“无用”的一些废话。因为我们既没有办法认为它对，也不能认为它不对。

所以，有时别人的构架设计写得实在不像样子，我会帮着写，但写完后，对方把我的话很多都复述一次，加入到他原来的设计中，这个设计还是不对。因为架构设计的信息，不是存在就可以的，而是它必须存在在每个独立的“决策面”上，而且在这个决策面上，逻辑是被穷举过，排序过的一个最优选择，这个才是架构设计。没有这个决策面的存在，这个架构设计就没有意义了。

比如，状态机，就是一个独立的决策面，在这个决策面上，无论你对系统做什么刺激，它的行为都是可预期的，系统不会陷入无法工作的状态。但如果你的状态机只分析了部分的刺激，有些刺激是不考虑的。那这个就不构成决策面了。因为你这个不证明任何目标的可行性啊。这个状态机对还是不对，我们都不知道。因为它只有部分的信息。

又比如说Use Case视图，我们用这种方法来捕获“原始诉求”。比如用户跟我们说，他要一辆自行车。我们去分析他的根因，发现他的目的是去上班。我们用Use Case视图去捕获这个原始目标。这样当我们做自行车方向失败的时候，我们还可以走做Bus的路径，或者走滑板车的路径。只有上班这个原始诉求无法被满足的时候，我们的逻辑才会失效。如果你做这个原始诉求的抽象的时候，把做自行车的方方面面都放了进去，有时机油又是铃铛的，这个决策面上构不成一个可以分析这件事是否可以做的目标，也脱离了我们发现原始约束的目的，这个视图就整个都是废的。这个决策面就不存在了。

所以，架构设计的本质是制造一组决策面，让我们在进入细节前权衡我们细节的核心约束，每个这样的决策面，都组成一个可以通向目标的逻辑抽象，同时对多个可选的方案进行了最后选择，如果缺乏这些决策面，即使你提供了大量的细节信息，这个架构设计都是无效的。