前言：
什么是软件架构？不同的人，有不同的答案。因为架构无处不再，架构又有不同层面。
很多人都给架构定义，不同的人，对架构有不同的理解，很难统一。
本文是按照作者个人的理解，来展现一个程序员如何向架构师演进的路径。
第2章 解析软件架构概念
程序员要转向架构的第一道门槛就是：什么是架构？在众多定义中，如何立足自身的实际情况和起点，转型软件架构师？
2.1 软件架构概念分类
这个派别的思想源于建筑行业的架构，也源于架构这个单词本身，该派别人为，软件是一个系统，任何系统都是有组件、子系统、模块等组成的，通过分解还原一个软件系统，通过划分组件、子系统、模块来构建一个新的系统。
组成派是站在目标系统的角度，以目标系统为目标和中心。
决策派站在人的角度看目标系统，他们认为目标系统是人意愿的体现，是人的决策的体现，展现的是一种人对目标系统的一个愿景和规划。除了看得见的功能性需求，还包括了看不见的非功能性需求。
备注：站在程序员的角度，其实可以不用陷入到概念之争中，而是从实践出发，立足行为，先依葫芦画瓢，等进入高阶阶段后，再思考如何进行概念化和思想总结。
2.2 核心思想解析
2.2.1 关注软件系统的组成部分的分割与交互
任何系统，都是由各个子系统组成，子系统与子系统之间，子系统与外界一定存在一定的交互，没有交互的子系统是孤岛，注定没有存在的价值。组件本质是就是子系统。
2.2.2 架构是自顶向下逐步分层的树型决策
.......................................
2.2.3 架构无处不在
2.3 工程实践
2.3.1 基于手头上的实际代码理解架构
一方面，程序员能够跳出代码的细节，抽象出系统的架构。
另一方面，架构是不能脱离手头上的软件代码，重构架构，架构师的架构要落地，要有支撑点，在一个已有的系统上，架构是构建在代码之上的，是已有代码的抽象；在一个新系统中，代码是蓝图，是代码的蓝图，代码是按照架构的方式构建软件系统的。
一个好的系统，是架构师与程序员的通力合作和相互信任，程序员相信架构师的架构能力，架构师相信程序员的编程能力。
2.3.2 架构是类的抽象定义吗？
架构师如何只定义类的抽象定义，程序员只按照抽象定义去实现，就不需要架构师这个角色了，优秀的程序来充当就可以了。
架构师做能够程序员的基础上做增量工作：
在更高层次上抽象系统，而不是类级别，如业务需求层面、用户层面和逻辑功能层面进行抽象，而类是实现层面的抽象。
除了功能性需求，还要关注非功能性需求，确保架构的系统满足未来的需要，而不是仅仅当下的需要
架构师要引领未来的方向，软件代码是满足业务需求的，软件架构要能够为当下的业务服务，同时也能适应未来的业务需求，只能需要有演进线路。
2.3.3 架构师不是需求工程师
架构师不仅仅要提软件的功能和非功能需要，还需要给出具体的技术方案，这是架构师与需求工程师最具备价值的地方。比如采用什么样的设计模式，技术方案选型等等。
2.4.4 不同派别不过是站的角度不同
感悟：
架构的思想，不仅仅适合软件系统，也适合任何系统，包括国家、企业、公司、组织、团队。
架构不仅仅是看得见的功能性需要，也包括看不见的非功能性需要，如稳定性、可靠性、安全性、伸缩性等。
架构是不同层面上的抽象，是业务目标的一步一步实现过程：业务需求层=》用户层=》功能与非功能层=》代码设计=》代码
