架构漫谈读后感
读了架构漫谈的博客，在前三篇中，他分别通过架构的概念，通后概念认识架构，以及识别问题三个方面进行了分析。
架构漫谈（一）架构的三重定义，在文章中，作者由架构的产生开始说起，一步一步的结束架构的定义，在文章中共说了三次架构的定义，通过对建筑进化的例子，是我更加能够体会到架构在我们生活中的重要性，在文章中他明确的指出架构概念。
- 架构在软件发明时的N多年以前，就已经存在了，这个词最早是跟随着建筑出现的。
- 架构的定义：体系架构包含建筑的过程和规划，产品设计，以及建筑和其他物理结构。
- 架构的产生：最开始的产生，是在原始生活中通过每个人完成不同的分工，以使得使得每个个体都拥有生活必须品，而不需要每个个体做所有的事情，只需要每个个体做好自己擅长的事情，并具备一定的交易能力即可。形成社会架构。
- 重新定义架构：把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。
- 架构产生的动力：必须由人执行，每个人的能力有限，时间有限，人对目标系统有更高的要求，目标系统的复杂性。当这5个条件同时成立，一定会产生架构。从这个层面上来说，架构是人类发展过程中，由懵懵懂懂的，被动的去认识这个世界，变成主动的去认识，并以更高的效率去改造这个世界的方法。（建筑的例子，原始社会分工的例子）
- 再次定义架构：根据要解决的问题，对目标系统的边界进行界定；并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间；并对这些切分出来的部分，设立沟通机制；使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
- 架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。（分久必合，合久必分）
架构漫谈（二）认识概念，在第二篇博客中，作者通过对于概念这一词的介绍与解释，来为我们介绍做好的架构必备的能力，以及结构实际上解决的问题。 架构实际上解决的是人的问题
- 概念，古时称之为名相。相实际上代表的是这个作用，并不是具体的某个东西，而名是用来标识这个作用的，用来交流的。
- 概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定概念。
- 抽象与概念的区别：抽象是把不同的概念的相似的部分合并在一起，形成一个新的概念。形成的新概念与原来的概念并不一样，所解决的问题也不一样。所以我们不能用抽象来定义一个事物，抽象实际上是一个分类的过程，完全是另一码事
- 概念与架构的关系：要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。
架构漫谈（三）架构之识别问题，在第三篇的博客中，作者向我们介绍了当我们作为架构师，在我们面对问题时应当如何识别问题。明确问题的主题，再进行架构设计。
- 识别问题：所有的概念基本都有一个很大的问题，就是缺乏主语。所以识别问题的一个最大的前提就是要搞清楚：是谁的问题。这个搞清楚了，问题的边界也就跟着确定了，再去讨论问题才有意义。（煮土豆）
- 作为软件工程师或者架构师，我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。找出问题的主体，是做架构的首要问题。这也是我一再强调的，我们要解决的问题，一定都是人的问题。更进一步，架构师要解决的，基本都是别人的问题，不是自己的问题。再进一步，我们一定要明白，任何找上架构师的问题，绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。
- 识别用户究竟是二传手，还是问题的真正主体。（锤子）问题的主体对问题的边界确定有多么的重要。
- 正确认识问题：这是谁的问题？有什么问题？
