最近在学习许式伟的架构课（https://time.geekbang.org/column/intro/166），收获很多。
其中架构思维，讲到了架构思维，或者说设计模式的正确打开姿势
架构思维的确是有很多共性的东西，值得我们总结出来细细体会。比如 “开闭原则”，多么有力的架构思维的总结，值得我们时时拿出来提醒自己。不过，我个人不太喜欢常规意义上的 “设计模式”。或者说，我们对设计模式常规的打开方式是有问题的。理解每一个设计模式，都应该放到它想要解决的问题域来看。所以，我个人更喜欢的架构范式更多的是 “设计场景” 的总结。“设计场景” 和设计模式的区别在于它有自己清晰的问题域定义，是一个实实在在的通用子系统。是的，这些 “通用的设计场景”，才是架构师真正的武器库。如果我们架构师总能把自己所要解决的业务场景分解为多个 “通用的设计场景” 的组合，这就代表架构师有了极强的架构范式的抽象能力。而这一点，正是架构师成熟度的核心标志。
架构设计的目的，说到底是为了解决业务中的问题，解决方案都是要带着场景来说问题的。有时候，作为程序员（包括我自己），我们通常喜欢脱离场景，一上来就大谈框架，模式等等，忽略了具体的业务场景。现在看来都过于浅薄了。弄清楚场景，划分清晰的问题域，是架构设计的前提。
再列一下课程中提到的架构师的心性要求
- 同理心的修炼：认同他人的能力
- 全局观的修炼：保持好奇心与韧性
- 迭代能力的修炼：学会否定自己
架构就是业务的正交分解。每个模块都有它自己的业务。这里我们说的模块是一种泛指，它包括：函数、类、接口、包、子系统、网络服务程序、桌面程序等等。它看似简单，但是它太重要了，重要到需要单独一讲来把它谈清楚。它是一切架构动作的基础。架构行为的三步曲：“需求分析”、“概要设计”、模块的 “详细设计”，背后都直指业务的正交分解，只是逐步递进，一步步从模糊到越来越强的确定性，直至最终形成业务设计的完整的、精确无歧义的解决方案。
“框架，提现的是需求泛化的能力”。
体现需求泛化的能力，就是架构可以适应需求的变化。需求的变化就是接口的变化，接口代表需求。
接口代表了要做什么，需求就是一个要做什么的集合，是目的。接口是需求的流程分解，即可以体现用户地图。
程序分为算法和数据结构，业务分为接口和业务数据，业务数据是业务的沉淀，是比框架更稳定的东西，而接口是在数据之上的动作，所以位置最高。