漫谈架构——读后感
今年，新开了一门软件工程的专业课，名字叫做软件体系结构。软件体系结构是具有一定形式的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。而软件体系结构中最为重要的是对架构的理解和应用。架构作为这门课程的重要的词语，在王概凯Kevin的架构漫谈中有了更加深刻的理解，对于架构也有了一个初步的新的认识，理解这些基础概念对于做架构是非常重要的。
首先，第一个问题什么是架构？
架构，英文的定义是：
Architecture (Latin architectura, from the Greek ἀρχιτέκτων arkhitekton"architect", from ἀρχι- "chief" and τέκτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures。
架构是规划、设计、建造建筑物和其他物理结构的过程和产物。
看起来很难理解，所以咱们再重新理解一下：
把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。
这样，就可以理解到ssh框架的架构的含义了：
Struts作为系统的整体基础架构，负责MVC的分离，在Struts框架的模型部分，控制业务跳转，利用Hibernate框架对持久层提供支持。Spring一方面作为一个轻量级的IoC容器，负责查找、定位、创建和管理对象及对象之间的依赖关系，另一方面能使Struts和Hibernate更好地工作。
Struts,Hibernate,Spring各司其职，分别承担着不同的功能作用，承担着不同的角色，他们进行分工，但又联合紧密，形成了一个整体，这就构成了一个框架。
Kevin总结出了构架产生的动力：
1.由人执行的工作。
2.每个人的能力有限。
3.每个人的时间有限
4.人对目标系统有更高的要求
5.目标系统的复杂性使得单个人完成这个系统，满足条件2，3。
为什么产生了构架?是因为社会的发展，我们学会了偷懒，学会了进步，理解到了分工的必须，以及分工之后带来的好处。
至此先初步总结一下什么是架构：
架构是为了解决一个问题，对解决的方法进行分工，但是这些分工要建立起沟通机制，重新组成一个完整的解决方案，完成目标的工作。这个过程，就是架构。
架构实际上解决的是人的问题：
如何理解架构，如何有效的去认识架构？这就需要们能够认识到概念的含义：
什么是概念，怎样理解概念？
概念是一个名字，每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。
所以，我们明确概念的最重要的步骤，是考虑到这个物或者是方法，是为了解决人的什么问题的，从这个角度才能够深入的理解概念。
回过头来，根据架构的定义，要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。
好了，知道你现在已经能够很好的理解什么是架构了，那么，新的问题来了如何能够成为一个合格的架构师呢？
作为软件工程师或者架构师，我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。只有真正明白了是谁的问题，才能够真正地完成自己的任务，真正地把自己的问题解决掉，而不是反过来。找出问题的主体，是做架构的首要问题。我们要解决的问题，一定都是人的问题。更进一步，架构师要解决的，基本都是别人的问题，不是自己的问题。再进一步，我们一定要明白，任何找上架构师的问题，绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。
软件架构师做什么工作呢？
软件架构师要做的就是从做好架构出发，让软件工程师写好代码，架构师对需求以及问题做好了分析和切分之后，设计系统框架，然后程序员按照框架来编写代码，如果最终编写出来的软件不能用来解决用户的需求或者问题，或者太复杂繁琐，说明在整个系统架构是上出现了问题，而一个好的架构师则会充分做好软件架构，包括代码架构以及承载代码运行的硬件部署架构，设计出来的框架会真正的解决各方的问题包括自己的。
做为软件架构师，其主要角色应该是解决业务问题，至于技术问题应该交给技术人员，自己专注于软件本身的架构，当然在解决业务问题的过程中，软件架构师还要准确识别要采用什么技术来解决问题更加高效方便，这个能力也是软件架构师所应该具备的。考虑的主要因素也是长期的成本和收益。