.. Kenneth Lee 版权所有 2019-2020
:Authors: Kenneth Lee :Version: 1.0
利益链
本文为我的架构定义名称空间引入一个新的概念，利益逻辑链，简称利益链。
利益逻辑链是一种逻辑链，逻辑链的定义在这里：:doc:关于设计方案中的逻辑链问题
。对于设计来说，逻辑链的每个节点（因果）都是一个约束或者限制，因为如果你承认这
个逻辑链（假定已经化简为最简逻辑链了），就表示你承认你必须符合这个逻辑链每个节
点的定义，你才能达到目标。
逻辑链就是约束，就是限制。限制影响了构架应对变化的空间和能力。选定了Linux做系统 的底层OS，就限制了你不能用Office来编辑Word文档。但进一步说，“选定Linux做底层OS” 制造的限制，不能代理为“不能使用Word文档”这种限制，因为Linux上确实有可以打开Word 文档的软件。
很多设计师喜欢限制，因为限制其实降低了设计本身的难度。编某个程序只能用C++，这个 设计点就结束了，不用再纠结于用不用Python，Ruby，Bash这样的问题了，也可以做出“在 C++编译器上加一个函数统计特性，则可以统计全系统的函数调用数量”这种设计要求了。 这个降低工作量。但架构师不喜欢这个，因为架构师最怕就是先选择了C++，然后发现对手 用的是Golang，结果对手的竞争力比你强，你怎么追都追不上，你的所有设计，都已经依 赖你必须用C++这个前提条件了。架构师的工作就和设计师不同，他怕就怕引入了无效的限 制，然后团队投入了大量的工作，最后发现这个限制不是必须的。
所以，架构师控制架构，主要就是在控制这种类型的自由度，避免无效的逻辑链节点定义 ，限制住了整个逻辑链的生存能力。设计师负责增加逻辑（限制），而架构师在过滤逻辑 ，把多余的限制隔离在系统的核心限制之外。
而做这种判断的核心方法，主要是两个。其一是避免错误代理，比如前面的，“不能运行 Office”，不能被代理为“不能编辑Word文档”。以前我写过的比如：
:doc:`弟子规：美国军方禁止在C语言程序中使用malloc`
也是这类问题。这种方法是就信息谈信息的，主要是避免信息本身传递的错误。
另一个判断方法是外在的，是判断一个限制的定义，是否在“利益链”上。所谓利益链，就 是这个逻辑链或者逻辑链的一部分，是否包含了被承认的有可见利益的“原始因”。这样的 原始因称为这个子逻辑链或者限制的“原始利益”。
举个例子，比如有个设计组提出：全部代码必须使用C++写。
没有问题，你提出这个全局限制了，逻辑链是什么？支撑这个逻辑链的原始因是什么？
“C++是个好语言”，“C++可以用模板”，“C++支持多态”……
这些原始因看不见钱，看不到可见的利益，用了你这个方法出了问题，你也背不了这个锅 （把你辞退你也赔不了这个钱），这个限制就不会被引入全局逻辑链。
“客户系统上只有C++编译器，如果不是C++，客户系统一定用不了”
嗯，这个是可见利益，整个项目成败被它左右。架构师需要过滤一道——它引入的限制应该 是：“插件系统必须只能由C++编译”。这是过滤错误代理。
这样，这个限制就叫“有利益链支撑的”。
利益是个认同的问题，你认为是个利益，我不一定认为。但对于一个集体，如果把问题摆 出来，什么是被承认的利益，什么不是，还是显而易见的。用利益链来分析问题，可以避 免很多神棍式的营销。比如“每天读一遍道德经，十年后你就飞升了”，“熟读弟子规，你就 懂国学了”，“按编程规范写程序，你的产品的质量就好了”……这些都是断裂的利益链，骗骗 不愿意动脑的傻子而已。
在实际中，利益链在架构讨论中常常非常微妙。不见得像上面这样显而易见。比如，有芯 片开发组提出这个特性：进行系统调用的时候，我自动帮你保存所有的寄存器。
我会反对：这个特性没有利益链支撑。
芯片开发组会这样说：难道软件不需要保存寄存器吗？
“需要，但这只能由软件开发组提出来。因为他们有利益链支撑，你没有。你可以建议他们 提出来，但不能是你们提出来”
这话听起来好像在争地盘，其实不是，因为芯片团队没有软件团队的语义空间，你的需求 是粗糙的，比如，你会保存所有的寄存器，但软件团队可能只需要保存其中3个寄存器。他 们提出保存这三个寄存器，他们必须给出他们的原始利益（比如，如果不保存这三个寄存 器，就无法进行进程切换）。证明竞争对手没有任何其他方法比保存这三个寄存器更快的 手段。但芯片设计团队是没有能力给出这样的证明的。这个原理，反过来也是成立的，软 件不能提出某个指令必须OoO执行，因为他们也不掌握芯片相应模块的组织方式，无法给出 背后的利益。
总基于利益链来讨论架构，我们才能保证我们的每个限制都是一个竞争力，才能保证我们 可以有足够的空间活下去。这对于长久的，生态的，初期的项目尤其重要，没有这个，死 都不知道怎么死的。