初步想想什么是架构的思维？

     在团队中，总听到大佬说：一定要学会用架构的思维去思考问题。这句话让我很感触，用架构的思维，那什么是架构的思维呢？

     写过代码的同学，甚至写了很多年代码的同学，都知道开发很多时候的代码大多都是CRUD或者CV，我也不例外。每天重复这样的工作，对人的成长毕竟有限的。

     我有时候也开始想，自己做的工作成长的方向在哪里？就像升级一样，我们也曾梦想从初级到中级再到高级，甚至是成为一名架构师。架构架构，当想成为高级的时候，就要具备初步的架构想法了。

     要开始有一个思维的转变，那就必须先提及一个问题：架构的思维和程序设计的思维有什么区别？

     是的，很大层面很多时候，我们使用的还是程序设计的思维，我们都知道，程序设计的思维是什么？是逻辑，是实现。包括你平时业务逻辑，用什么设计模式让你的代码更好维护更好扩展之类的，等等。这些都还仅仅是程序设计。

     那什么是架构的思维呢？是判断，是选择。简单一个例子：就好比你和第三方的一个交互，可以是同步，也可以是消息队列的异步？两种方式都没有错，这个时候你会怎么选择？       假如你的系统使用了异步，又可曾想过为什么？你肯定知道的是，引入一个中间件，必然会增加系统的复杂性。这其中怎么选择，这就涉及一个小的架构思维了。

     那架构和框架又有什么区别呢？

     架构强调的是系统的结构，而框架更加强调的是一种规范，或者说是一种使用上的规范。当然，这里好像也是强行区分了。毕竟，你要说Spring，你说他是框架，难道里面没有架构吗？这里这么说，想表达是：希望能站在一个更高的角度，去思考你这个系统到底要怎么运作，然后告诉自己为什么？架构要解决什么问题？我们总说当然高可用、高扩展、高并发等等。可是，什么系统都需要做这种设计吗？举个例子：一个学生管理系统，学校平均每个学生每天访问不到1次/天，高并发会成为你系统设计的瓶颈吗？显然不是。又比如，这个系统即使断电两个小时，对学校的影响大吗？我想，至少没有淘宝、天猫断电一两分钟来得大吧。所以架构架构，解决的肯定是系统最复杂核心的那些问题。

     写到这里，突然想到一个值得一说的事情，就是平台能力。比方说我们要去做一个系统，业务诉求总是在变，总是要改，然后我们就开发，这样是不够的，因为需求是永远做不完的，不断衍生的需求，最后只会迫使你不断地重构或者升级系统。需求是做不完的，但是平台的能力可以，要不断地去沉淀平台的能力，这个才是我们更加值得关注地事情。就好比说DDD，怎么去定义好你的领域模型，让你的业务框架更好的和技术框架协同发展？这些不都是很有意思的问题吗？

      当然，这些都是在我真的设计过技术方案有的一点感悟。每次设计完技术方案，都深化了自己的理解。当然，自己的方案，自己开发，有坑也只能在自己背了，哈哈。不过团队还是会有很多大佬评审出你的方案问题的，所以，大胆用心的去思考就好。还有很多很多需要提升理解的东西，加油。