[笔记] 02 架构设计3个原则

从程序员到架构师，有一个明显区别：不确定性。
编程执行的结果是确定的。架构设计，本质上是不确定的。用不同架构去做同一个需求，可能都能正常运转。但架构设计还是有一些隐含的共性原则的。

合适原则

合适优于业界领先。
优秀的架构，都是在企业当前的人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起，发挥最大功效，快速落地。
追求极致技术的架构，可能工作量远大于实际人力，可能没有实际场景的积累，可能想依赖天才的灵感、可能脱离了具体业务……必然失败。

简单原则

架构设计是技术活。历史上的技术活，无一不是越来越精细，越来越复杂。软件的复杂度体现为：

1. 结构的复杂性
2. 逻辑的复杂性
   降低结构复杂，就必然增加逻辑复杂；降低逻辑复杂，也会增加结构复杂。所以，如果能简单时，请选择简单的方案。KISS（Keep It Simple and Stupid）。

演化原则

演化优于一步到位。
软件架构和建筑架构是最常一起比较相似性，但两者有个本质上的差异：建筑一旦完成(开工)，就不可再变；软件却需要根据业务发展不断变化下去。前者的主题是永恒，后者的主题是变化。

误区：试图设计一个软件架构，期望无论业务如何变化，架构都稳如磐石。
其实，架构设计更应该类似大自然设计生物的思路，不断演化和适应。