标签：
听到构架，我最先想到的是一个软件系统的轮廓，就像建房子时要先给房子画一个设计图，这个房子的外形是什么，同样我认为软件系统的构架就是要实现什么样的功能，它的界面布局是什么，都有哪些功能模块。在接触了“软件体系结构”这门课以后，我知道了构架是软件系统的一个或多个结构。这些结构是由软件元素、元素的外部可见属性以及这些元素之间的关系组成。
在阅读了“架构漫谈”这系列专栏以后，我知道了软件构架不仅仅只是软件系统的构架，它受很多方面的影响，同时也影响了很多方面。“架构漫谈”提出架构就是对要解决的问题进行目标系统的界定，对目标系统按某个原则进行切分，并对切分出来的部分设立沟通机制，使得这些部分之间能够进行有机的联系成为一个整体，完成目标系统的所有工作。对于架构的解释，有好几种回答。每个人都以为自己已经理解了架构的概念，但其实都不是很确切的，只知道是那个意思，至于为什么是就没有解释了。
对于抽象，我本身没有很多的认识，感觉自己想像不出来的就是抽象，跟主观看到的不一样的就是抽象。“架构漫谈”将抽象的含义解释为把不同的概念的相似的部分合并在一起，形成一个新的概念。这使我对抽象有了一个新的理解。
架构解决的是人的问题，知道了是解决人的问题，就很容易知道有什么问题要解决。这就需要架构师了，一直觉得架构师是一个技术水平很高的职位，他所做的就是设计系统的功能，设计系统的整体样式。“架构漫谈”提出一个只致力于完成自己的工作，已做好自己的工作为主要目标的人是无法成为一个架构师的。要成为架构师，就要超越一个恐惧，这个恐惧就是在按时解决别人的问题成为自己的问题的时候，就会有时间压力，就会产生一种对时间的恐惧。因为有恐惧存在，我们会采取各种手段，来及时的完成工作，换取报酬。其还提出架构师必须是一个组织的领导人，这是我没有想到的，我一直以为架构师就是将系统的架构报告给领导有领导来组织人员实施，架构师只要有技术就可以了，其他的不用管。看来架构师不仅有技术的要求，对业务领域也是有要求的。
代码也是需要架构的，“架构漫谈”将代码分成的部署单元所承担的责任分为两个：表达业务逻辑的代码和对用户提供访问并保存业务逻辑运行结果的代码。对于第二个责任我不是很明白，感觉是不是用户界面之类的代码。
一直以为软件架构只是技术的问题，跟业务没有多大的关系，架构只是解决的软件设计的问题，现在看来自己的理解有很大的问题，有很多不足的之处。
标签：
原文地址：http://www.cnblogs.com/fengyutongxing/p/5443917.html
