个人这些年，从web->system service->app 项目实战，陆陆续续经历的项目很多，自己也数不清。自己也一直对于架构没有明确去给出一个自己的定义描述。

刚好最近一直在flutter折腾，感触良多，就整理了自己对于架构的心得体验。

架构说直白一些就是3步套路（抽象、分治、演化）的走法就可以设计出一个不算差的架构，这些年经历和设计出的项目，于我而言，架构无非2类实现方式，它们都殊途同归：一种是直接抽出核心点，简化逻辑，实现最小功能逻辑验证可行性，然后推出宏观架构，一切围绕核心点去架构（自底向上）；，另一种方法就是直接宏观方向进行架构，拆分出业务组件、模块，梳理之间的关系流程得出基础架构，再根据基础架构快速实现各基础模块来验证和改进。（自顶向下），

以上2种方式虽然顺序不同，但是都是围绕【架构核心】的3个点进行：

1）抽象—>分层：抽象在我看来，就是一句话：跳出细节去思考总结，产生概念性的标记对象，宏观去描述业务逻辑。而分层，是从也是宏观去实现，每一层为解决特定领域问题而产生的解决方案，为向上提供服务，有些层会贯穿其他层提供服务，就可以认为是共享层，比较容易理解分层的就是mvc。

2）分治：是应对和管理复杂业务的通常手段，有句经典“一切皆接口”，越是编码，越有这样的体会，分治在我看来就是大问题无法解决，就拆分小问题，通过类似接口、方法、事件等手段分解之后将小问题组合起来的解。

3）演化：社区也经常有人讨论演化和架构的关系，社区有2种主流：偏架构方法流，还有一种就是偏演化流，在我看来演化是架构去其糟糠取其精华的体现，个人比较喜欢，只有经历过版本的架构（抽象、分治）才能有演化这一步，不断演化才能优化出一套最适合团队的输出物。又比如微服就可以算是演化流，但是从宏观去考虑，微服务又是先架构后演化，后期的演化会推动架构的不断进化。