关于架构设计的一点心得

架构就是业务的正交分解。每个模块都有它自己的业务。 这里我们说的模块是一种泛指，它包括：函数、类、接口、包、子系统、网络服务程序、桌面程序等等。架构行为的三步曲：“需求分析”、“概要设计”、模块的 “详细设计”，背后都直指业务的正交分解，只是逐步递进，一步步从模糊到越来越强的确定性，直至最终形成业务设计的完整的、精确无歧义的解决方案。

框架体现需求泛化的能力，就是架构可以适应需求的变化。需求的变化就是接口的变化，接口代表需求。 接口代表了要做什么，需求就是一个要做什么的集合，是目的。接口是需求的流程分解，即可以体现用户地图。 程序分为算法和数据结构，业务分为接口和业务数据，业务数据是业务的沉淀，是比框架更稳定的东西，而接口是在数据之上的动作，所以位置最高。

架构过程是团队共识形成与确认的过程。共识是需要精确的、无歧义的。而架构图显然并不精确。更精确描述架构的方法是定义每个模块的接口。接口可以用代码表达，这种表达是精确的、无歧义的。架构图则是辅助模块接口，用于说明模块接口之间的关联。

架构师的能力：

1. 理需求的能力；
2. 读代码的能力；
3. 抽象系统的能力。

架构师的心性：

1. 同理心的修炼，认同他人的能力，不要在没有全面理解他人思想的情况下，去调整既有代码的设计逻辑。
2. 需要对一个需求场景有多种实现路径的思考与评估。
3. 全局观的修炼，保持好奇心和学习的韧性。
4. 迭代能力的修炼，学会反思，学会在自我否定中不断成长。

架构设计会有它的一些基本准则。比如：

1. KISS：简单比复杂好；
2. Modularity：着眼于模块而不是框架；
3. Testable：保证可测试性；
4. Orthogonal Decomposition：正交分解。