说到架构，本人其实从总体感觉上来讲，都差不多，尤其是现在互联网体系
我认为架构一个系统，要分为两部分考虑，
第一：从系统总体的角度考虑，包含，系统的定位，系统的大致访问量，系统的要求完成时间等等，就是站在一个宏观的角度考虑采用什么样的方式和组件来搭建系统的基础部分。这部分感觉烂大街的东西了 ， 缓存，数据库，开发框架，mq，rpc通讯框架或者rest等等，然后具体到各个解决方案的问题。比如，缓存、数据库、mq怎么搭配怎么用 啊之类的。是不是考虑读写分离啊，是不是要限流啊，林林总总。
第二： 从业务角度的考虑，就是所谓的代码架构，其实这还是比较有含量的，因为代码架构合理的话，会为后期开发维护提供很好的清晰的思路，会让人很舒服。比如：系统出现了问题，能够快速的定位到发生问题的地方，查找代码也是有依据的，非常的快速。不然，如果架构不清晰，代码混乱不堪，那真是有的受了。从代码架构的角度考虑，我提出自己的观点：面向对象的架构方案。
什么是面向对象的架构呢？ 其实思想还是来源于面向对象编程，主要讲究个抽象、封装、继承、多态、对修改封闭，对新增开放。比如：根据业务需求，首先进行业务抽象，抽象出业务的本质、封装业务本身的独特、各个业务继承同质的东西、每个业务实现同质的抽象（多态），这就是代码架构的终极奥秘。
只要理解了这几句话，自由发挥，可大可小。设计模式也是这个意思，不能过度设计，亦不能不设计。