.. Kenneth Lee 版权所有 2021
:Authors: Kenneth Lee :Version: 1.0
最近在评审一个架构设计的时候，又发明了一个新概念，叫“决策面”，本文细化这个概念。
被动写的架构设计很容易陷入一个陷阱，就是为写架构设计而写架构设计，而不是为了设 计而做架构设计。
所谓“被动写”，常常出现在组织流程上要求写架构，或者学习写架构的人希望“正确地写架 构设计”。我以前用“我没错”这个概念去解释这个问题：
:doc:`架构设计的大忌：我没错`
但“我没错”是个反向的定义，只定义什么不对，但没有定义什么是对的。你不可能要求做 架构设计的人主动做一个“有错”的设计对吧？但“对”的架构设计里面，我们还是可以发现 很多例子，这些例子中，它的“设计逻辑”确实没有什么用，这是为什么呢？
真实的设计有非常多的细节，我们还是用简单的事情作为类比比较容易突出这个主题。比 如说我们要过河，如果我们抱着行李直接下水，这就叫“没有架构设计”，因为我们没有一 个总体的打算，下去随着水浅的地方走啊走，可能最后走回到同一侧的岸边去了，也可能 走到水流湍急的地方直接被冲走了。
我们做架构设计，是为了在整体上分别处理我们的细节，这样我们成功的机会就变大了。 比如我们看好中间有一个小岛，我们分两步走，第一步先到达那个小岛，第二步从小岛去 对岸。我们觉得这个设计是必要的，因为没有这个设计，我们就会刚才提到的，走下去回 到同一侧。这是我们引入架构设计的原因。
但如果你的架构设计要做样子，说我们需要先到一个小岛上，然后从小岛过去。但这个逻辑 和是否能到对面没啥关系，这个设计就变成了做样子了：样子上，你和前面我们认为是架构 设计的那个逻辑很像。但你能总体上解决能否过河这个问题。
请注意了，你说先去一个小岛，然后过河，这件事还真的可能和过河有点关系。但它不是 一个完整的说明如何过河的逻辑。我们设计需要一个完整的逻辑，说明我们先去小岛，然 后过河，确实是可以过河的。为了证明这一点，我们可能还有其他证据，比如去小岛和小 岛去对岸，都是有浅水区可以淌的。在我们下水前，我们没有所有的细节，但我们必须有 置信度，让我们放心敢选这个方向过河，这不是个事实的问题，而是个信心的问题。所以 ，它是一个抽象的东西。这个东西，我就称为“决策面”，一个决策面，是一个抽象，从我 们认知的事实抽象，得出，XXXX方案是一个可行，接近最优的选择。所以，决策面是一个 可以权衡和证明目标的“视图”，如果你的设计（呈现为一组Rule或者Constraint）不能构 成这样一个决策面，它就是“正确”但“无用”的一些废话。因为我们既没有办法认为它对， 也不能认为它不对。
所以，有时别人的构架设计写得实在不像样子，我会帮着写，但写完后，对方把我的话很 多都复述一次，加入到他原来的设计中，这个设计还是不对。因为架构设计的信息，不是 存在就可以的，而是它必须存在在每个独立的“决策面”上，而且在这个决策面上，逻辑是 被穷举过，排序过的一个最优选择，这个才是架构设计。没有这个决策面的存在，这个架 构设计就没有意义了。
比如，状态机，就是一个独立的决策面，在这个决策面上，无论你对系统做什么刺激，它 的行为都是可预期的，系统不会陷入无法工作的状态。但如果你的状态机只分析了部分的 刺激，有些刺激是不考虑的。那这个就不构成决策面了。因为你这个不证明任何目标的可 行性啊。这个状态机对还是不对，我们都不知道。因为它只有部分的信息。
又比如说Use Case视图，我们用这种方法来捕获“原始诉求”。比如用户跟我们说，他要一 辆自行车。我们去分析他的根因，发现他的目的是去上班。我们用Use Case视图去捕获这 个原始目标。这样当我们做自行车方向失败的时候，我们还可以走做Bus的路径，或者走滑 板车的路径。只有上班这个原始诉求无法被满足的时候，我们的逻辑才会失效。如果你做 这个原始诉求的抽象的时候，把做自行车的方方面面都放了进去，有时机油又是铃铛的， 这个决策面上构不成一个可以分析这件事是否可以做的目标，也脱离了我们发现原始约束 的目的，这个视图就整个都是废的。这个决策面就不存在了。
所以，架构设计的本质是制造一组决策面，让我们在进入细节前权衡我们细节的核心约束 ，每个这样的决策面，都组成一个可以通向目标的逻辑抽象，同时对多个可选的方案进行 了最后选择，如果缺乏这些决策面，即使你提供了大量的细节信息，这个架构设计都是无 效的。