架构设计的本质是应对不确定性，而非编程式的确定性

优秀程序员和架构师之间存在一道明显的鸿沟，这道鸿沟的本质是”不确定性”。编程本质上不允许存在不确定性：同一段代码不管谁写、什么时候执行，结果都应该是确定的（这里的”确定”不等于”正确”——有bug的代码执行结果同样是确定的，只是确定地产出了错误结果）。架构设计恰恰相反，本质上是不确定的：同一个系统，A公司和B公司做出来的架构可能差异很大，但最后都能正常运转；同一个方案，不同设计师的判断可能截然不同，却各自都有道理——因为架构设计领域并不存在像编程语言语法那样的硬性约束，更多时候面对的是多种可行选择之间的取舍（如选业界最先进的技术还是团队最熟悉的技术、选Angular还是React、选MySQL还是MongoDB），而缺乏一套通用规范来指导这些选择，正是这种不确定性让架构设计常被视为一项带有”神秘感”的工作，也让新手架构师容易在选择面前陷入两难。这个不确定性的定位很重要：它意味着架构设计原则不是用来消除选择、给出唯一正确答案的规则，而是用来在不确定性中提供判断方向的经验总结——[[合适原则：合适优于业界领先，及其三个失败根源]]、简单原则、演化原则正是从架构设计发展史和多家公司实践中提炼出的三条这样的共性判断依据。