1.必须能落地 第二条的一种表现 虽然写在这里比较多余，但是还是需要着重提一下
2.合理 基于现有情况去做最好的设计 重点是基于现状也就是团队的上下文。几个关键点 资源（人） 时间 业务（复杂度与业务发展，比如一个一次性开发的业务还是长期维护的业务，1+1=2的业务还是非常复杂的业务，1个人使用的系统还是上亿人使用的系统，不同级别的系统设计力度肯定是不同的）
3.简单 这里有两层意思 本质是要在外部与内部复杂之间找平衡点
1.不要把简单问题复杂化，1+1=2不需要非得重载一个加法运算。
2.可以分为内部复杂度与外部复杂度，简单是指要在内部复杂与外部复杂找到平衡点。内务部简单必然引起外部复杂（外部的实现复杂或者依赖关系），业务是不变的，如果内部简单，必然有很多业务需要在外部实现。比如微服务来说，如果每一个服务都足够简单，则服务的依赖关系就会增多，这样不利于本地开发，问题排查更困难，故障率（服务增多，调用链路复杂）也会增加。业务是不变的，一个服务内部简单必然需要外部消耗。如果想要外部简单，则内部需要完成更多的逻辑，则此服务必然难以维护，因为内部逻辑太复杂了。
4.系统不是一蹴而就，是需要演进的 本质是指系统的进化需要跟着业务规模走 一个系统最开始的设计，一定要是合适（合理）的。什么样是合理的？1 能落地 2 在业务还没有发展到一定程度，先满足当前的业务。当业务规模不断扩大，迭代的增多，系统规模越来越大，系统将面临不同的问题。此时根据业务的增长规模去优化，重构系统。比如做一个交易系统，刚开始的业务只有几百，就没必要按照1亿访问的规模去设计，几百与1亿规模的系统的设计复杂度相差过多，资源投入也非常大。如果前期就投入大量的成本，业务没起来，这样的架构对于团队的价值么有意义，当然技术的角度上有意义，但是架构本身的最核心的价值观就是合理的解决方案，几百的规模直接设计成1亿本身就不是合理的做法。
架构我的理解就是合理的解决方案，上述的4条，都是围绕的这个理念衍生出来，本质就是在设计系统时不同的角度，不同阶段都要追求合理。架构本身是解决方案，但是必须是合理的解决方案才是架构。