这几天阅读了《架构漫谈》的前三章内容之后，对架构有了一个初步的认识，这几部分主要讲述架构的概念，什么是架构，以及架构的识别问题，同时在第二章为了能够更加清晰的引入架构，还对概念一词进行了详细的阐述，书中有很多生动形象的例子，对我们理解架构有很大的帮助。
首先什么是架构？架构，又名软件架构，是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。架构描述语言（ADL）用于描述软件的体系架构。架构一词其实并不是来源于我们软件行业，其最早出现在建筑行业，随着社会的不断的变化，人们根据自己的地域风格、采用各自的设计的方法，建造出风格各异的建筑。可以将架构理解为采用一个成熟的设计经验设计的一个整体的框架。
然后架构是怎么产生的呢？用书中所描述的话说就是因为随着社会生产力的发展，出现了一些在某些方面专精的人，逐渐的社会产生了分工，就把所有的事情，切分割成不同的人完成，最后再通过交易或其他方式，使得每个个体都拥有生活必须品，而不需要每个个体做所有的事情，只需要每个个体做好自己擅长的事情，并具备一定的交易能力即可。所以架构就是把一个整体切分成一个个小的部分，由不同人来完成这些模块，最后这些部分能够有机的结合在一起，并完成这个整体所需要的所有活动。当出现以下几个方面时
1.必须由人执行的工作
2.每个人的能力有限
3.每个人的时间有限
4.人对目标系统有更高的要求
5.目标系统的复杂性使得单个人完成这个系统比较困难，
这样就必定会产生分工，也就必定会产生架构。
架构就是为人设计的，没有人的参与，也就失去了架构的意义所在。然而架构需要解决什么问题，提出问题的主角，就像书中举例中提到的，切土豆的问题，丈夫是这个工作的熟练者，而且确实解决的是切土豆的问题，男主人也都尽职尽责的完成了，然而就因为忽略了问题的主题，就导致了这个问题的失败。上面的分析可以看出，找出问题的主体，是做架构的首要问题，对于一个架构师来说发现问题永远都比解决问题来的更加重要。一定要找到问题的实际主题，探究找到软件的直接使用者，解决的是软件在实际的应用中所要解决的问题。
总之，要想成为架构师，首先清楚的是两个问题。问题是谁的，问题是什么，这就是我对这本书前几章的一些理解。