3.71. 道法自然
在这里：逻辑链，道，学和架构工作的本质，定义了什么是“道”之后，我想我们开始有足够的名称空间来发展“道法自然”这个概念（和策略）了。
我们定义了，所谓“道”，就是逻辑链中组成事实的那条路径（注：路径可以是树）。考虑上时态，它包括已知逻辑事实和预期逻辑事实，某段逻辑链是否合道，随着时间，我们终究，很可能，会知道。
我们把我们定义的，未成为现实的，道，称为“将道”（如果你不喜欢“道”这种神秘兮兮的概念，我们把它叫做未验证逻辑事实），把随着时间推移，我们都确定，它是现实的，道，称为“已道”（已知逻辑事实）。
道永远都会往前走，无论你定义了逻辑链还是没有定义逻辑链，这个世界背后总有一个“道”存在。但这个理论没有用，如果按这样的理论，要“合道”，你自杀就可以了。所以，我们不是要“合道”，我们是要“解决问题”，是要“在解决问题的前提下合道”，所以才要加上我们的力量在内，决定力量如何投放。
“道”是个合力，你个人的力，你提取的逻辑链，都只是“合力”的其中一部分，而且很可能是微不足道的一部分，所以，要“解决问题”，要对道的方向造成影响，就需要和没有你在内的力量进行配合。所以，你定义的逻辑链（个人定义的道），必须和外界更强烈的逻辑链，能够配合，才能最终成为“已道”，我们要让我们定义的逻辑链变成真正的道，就需要“道法自然”。
我们基于已道，定义了将道，形成一个完整的逻辑链。这个逻辑链要最终合道，就需要减少需要加入“我的力量”的部分，这个优化策略就叫“道法自然”。
“自然”，就是“它自己要这样的”，没有一个“意欲”作用在里面。这其实背后隐含了这么一个意思：“现实是所有意欲的共同作用结果，没有任何一个意欲可以左右一切”。
这会有一个自然的推论：因为逻辑链定义了一个意欲，所以逻辑链必然是粗糙的，不精细的，精细定义的逻辑链必然不合道。
（顺便插一句——所以不要认为某个“完全不精确的意欲”在山顶上等着某个“比较精确的意欲”有多了不起。因为我们不是要意欲“合道”，我们是要解决问题）
所以，架构设计必然不是精细的，它可以很明确，但它肯定不精细，否则就容纳不了其他意欲在里面。
这个结论看着没有什么用， 不解决问题，但它是指导我工作一个很重要的判断。
当我接手一个产品的时候，我的感觉手里拿着一个装着不同大小的沙子，石子的玻璃瓶子，里面看着已经放不进任何新的石子了。而我的工作是摇这个瓶子，让沙子落到石子中间，最后这些沙子，石子就会形成一层一层的结构，原来不足的空间变得多了，石子和沙子形成的结构也变得坚固了，有力了。这个新形成的结构，就是我完成的架构了，这个架构和我的工作看着没有什么关系，因为都是石子和沙子主动运动形成的，但它确实形成了一个结构，这个结构就是架构，它不是我“设计”的，而是石子和沙子自己形成的，“功成身退，百姓皆谓我自然”。但没有我去摇这个瓶子，它并不会“自然”形成这个架构。
反过来，我看过很多失败的架构设计，都是架构师上来设计了很多层次，要求这个模块工作在这个层次上，那个模块工作在那个层次上，这里是什么什么接口，那里又是什么什么规范，最后也会形成“一层一层”的样子，但本来这些石头，沙子就互相冲突太多，导致竞争力不强，一盘散沙，你这些“构架工作”只是增加了更多坚硬的石头、木架，这个系统就更加地一盘散沙，你对外宣传这也是“架构”，外行只能看到这些所谓“分层”，“对象”，“封装”，却看不到丢失的竞争力，看起来很厉害，但实际只是个样子货。
所以，架构工作怎么做呢？架构工作是看利益来的，首先我们必须定义，我们整个集体，是什么东西在埋单的，可能是市场盈利，可能是战略期望，反正这群人能存在着，干这个活，背后总是有东西在支撑的，这个支撑被什么判断逻辑所支持，这个是比较容易找到的。这个东西东西我不需要表述出来，但它可以变成“架构需求”，展现在整个团队中。
下一步呢，就是架构定义了，正如前面说的，它会非常简单，它可以很Solid，也可以完全不Solid，只是现在的打算，到架构目标最终实现的时候，它可能“事如春梦了无痕”。
而架构师大部分可以看到的工作，可能就变成基于架构定义和架构需求，进行文档评审，具体进行关键设计或者非关键设计（用作范例，为天下式），设计代码，进行测试（了解实际实现情况）等等。但架构师不是万能的，所以，这些工作他也不能深入做，一旦这个事情做到“上了正轨”、“已经了解情况”这种程度，就要让给其他设计师来填补，自己用架构目标丈量一下现在的状态，然后填入下一个没人肯填的坑里面去。
另外，为了保证不会一直“不务正业”被人刷了，架构师同样在一定程度上必须“求名”，在一两件事上Shining一下，否则自己都被人割了，也无法最终合道。
所以架构工作是没有模式的，这就是架构工作的“道法自然”。
我好奇的是，当你想明白这些逻辑后，还想做架构工作吗？
曾经沧海难为水，除却巫山不是云。 天若有情天亦老，人间正道是沧桑。