通过对架构漫谈的观看，我对架构有了新的认识与感悟。
首先需要知道的是，架构不仅仅存在于软件行业，大到一个国家，小到一个企业，组织，甚至是一段音乐，都有自己的架构，架构可以帮助人们充分认识问题，解决问题。
一直以来，总觉得架构是一个很高深的词汇，给人一种虚无缥缈的感觉，而在软件行业，对于什么是架构，业界一直都存在着许多争论。在刚刚进入软件工程专业，听到架构和架构师这两个名词的时候，就觉得组织架构是一个架构师的基本技能，而当时仅仅认为架构师就是能设计出更好程序的程序员。但是经过对架构漫谈系列专栏的阅读，我深刻认识到，架构并不是仅仅编写出好的程序这样简单，它涉及到的是一个整体的概念，而非局部，只有一个整体才存在架构的概念。就像一个hello world程序，它是不存在架构这样一个概念在里面的，而对于一个系统，比如淘宝这样的一个电商系统，谈起架构来才有意义。
我理解的架构存在于复杂的软件设计中，它指定了复杂系统的边界，同时把一个复杂系统划分为多个部分，比如，一个电商系统，包含供方，商品，合同，订单，库存，促销等多个部分，那么这些部分之间就存在着潜在或者直接的联系，每个部分又可以单独进行开发，那么如何组织这些部分之间的沟通机制，如何设计接口，分配工作，这就是架构的内涵。也就是说，一旦涉及到团队工作，目标系统足够复杂且个人能力有限，这个时候架构才会产生。架构是我们提高效率，充分认识我们的软件的方法。
在架构漫谈的第二篇中，作者提到了认识概念是理解这个世界的基础。概念这个词从我们很小就接触到了，像小学一年级，我们就理解了加法减法的概念，自然数的概念，后来慢慢的，我们又通过更多的概念，来提高我们的认知，了解这个世界。就像概念一样，架构也是我们用来理解这个世界的工具，或者说理解我们将要面临或者解决的问题的工具。还是以电商系统为例，比如我们要设计商品与订单两个子系统之间的联系，从单方面的功能看，商品模块就负责商品信息的展示，而订单模块负责订单的生成和展示，与此同时，两者又有这样的联系，订单模块需要获取商品的具体信息成交额度等等，那么如何建立两者之间的联系呢，这个时候我们想出了一个解决方案，我们姑且称它为架构，我们这样解决这个问题，从数据库表格下手，建立订单和商品的关联关系表，那么这个解决方案，其实就是我们整个软件系统架构的一部分。由此，我们就可以根据抽象出的架构的概念来理解什么是架构了。
在架构中又存在这样一个问题，那就是如何去识别问题。识别的问题可以是现实生活中的，也可以是我们软件系统中的，对于一个软件系统来说，如何识别软件系统的开发维护中可能存在的问题，也是我们建立架构的第一步。那么在这里，我们首先需要弄清楚的就是问题的主语，也就是谁的问题，这样的做法首先就是用来确定系统的边界，再拿电商系统为例，比如我们的商品系统，商品是要展示出来的，那么，问题的主体是什么呢，是用户，是买家，确定的问题的主体，就会衍生出一系列约束，比如，商品是用来展示的，是要给买家展示的等等。所以我们如果想要做架构，找到问题的主体，是我们的首要任务。是什么问题，是谁的问题，有什么问题是我们不得不去考虑的事情。
在识别了问题之后，我们就要对问题进行切分了，通俗来讲就是分工。比如我们发现了商品系统中的商品展示问题，那么，商品的汇总展示，和商品的个体展示完全可以分工来做，这样的分工可以调整团队中的利益相关人，这样使得系统的开发变得更有动力，因为每个人都会为了自己的利益去努力。如果不进行切分，大家囫囵的一起做商品系统，这个时候就不只是混乱，在利益分工不明确的情况下大家的工作点和工作方向以及标准都会变得不确定，产品的质量也因此难以保证。
也就是说，当业务量大到一个人无法处理的时候，我们就需要用架构的思想来切分功能，切分职责，使利益分配更加合理，系统的沟通更加的顺畅，千万不可轻视切分这个层次，它是使得架构能够落地，保证人心不溃散的重要因素。
