对于架构这个概念，我还停留在架构就是站在一个全局的角度上，描述的是一个系统的草图，是直接构成系统的抽象组件，各个组件之间的连接则明确和相对细致地描述组件之间的通讯。这只是一个非常官方的了解，并没有我自己的认识。因为对架构的认识还很浅薄。在看了王概凯作者编写的九篇博客《架构漫谈》之后，我对架构有了一些更加不一样的认知和了解。
架构到底有什么含义呢，又为什么会产生架构呢？可以想一下，在最早时期的时候，为了解决人类延续的问题，自然而然就产生了男女的分工，这样就形成了人的分群，地域的分群。当发生分工以后，实际上每个人的生产力都得到了提高，因为每个人的能力是有限的，而且人的结构的限制，所以就产生了分工。这样的话，这些人就必须要通过某些机制何在一起完成所必需的事情，就导致了交易的发生。这实际上就形成了社会的架构。由此可以总结出架构的实际含义：把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动。而架构的目的实际上是解决人与人之间的利益切分。
我们在日常生活中，经常对一些东西习惯性的去认为，自以为明白的很清楚，实际上是想当然。但是在问不同的人的时候，得到的却是不同的答案。比如，这次在课堂上，老师问了我们，我们认为的桌子是什么，用自己的话语描述一下，并提问了几个同学。一位同学说：四个腿，一张面就是桌子。一位同学说：可以盛放东西的物体。另一位同学则是说：可以吃饭、办公的地方。但是我们大家想一想有四张腿和一个面的一定是桌子吗，凳子同样也是。可以放东西的也不一定是桌子。其实，这描述的就是在做架构的时候，不同角色的沟通会出很多问题，结果也就可想而知了。
想要做好架构的话，首先需要做的就是识别出需要解决的问题。用一句话总结就是，如果把真正的问题找到，那么问题就已经解决80%了，即架构的核心就是发现问题，解决的是人的问题。老师上课给我们举了一个例子，女主人公：老公，把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半，然后下锅。当时我们同学的大部分意见都是认为是沟通的问题。却忽略了问题的本质，也就是这个问题的实际目的。其实女主人公实际让老公解决的是晚饭。这件事教给我们只有真正投入思考问题是什么的工程师，才可能会真正的成长为架构师。那到底我们应该如何识别问题呢，第一点，要找到主体，也就是搞清楚是谁的问题。因为作为一个架构师，要解决的问题一定都是人的问题。自然而然就可以确定问题的边界了，也就是有什么问题。
架构在很多方面都是有应用的，但是我们关注的是如何运用架构思维，更好的设计和实现软件。那么软件是什么呢，软硬件两者一结合，就会出现电脑也就是可以编程的大脑，在硬件上编写出的程序，就是软件，是用来控制硬件的行为的。在软件越来越丰富的时候，能够做的事情也就变得越多了，而开发成本也越来越低。有了软件之后，我们就可以把日常生活中所做的事情虚拟化到计算机中。而软件工程师的工作就是实现这个模拟过程的关键人物。但是这个过程需要学习大量的各行各业的专业知识，所以需要很多角色。就开始了角色的切分，也就演变成了不同的软件架构来提升参与的人的利益，降低成本。软件需要解决的问题呢，有两点，一是业务问题，搞明白要解决的问题的主体是谁，解决的是什么问题，是如何解决，如何运作的；二是计算机问题，如何将现实生活用软件来模拟。这是软件的复杂所在。当软件因为流量增大而分拆成不同的运行单元时，会在不同的机器上部署所形成的架构，就属于软件架构。
代码架构对于我们来说，恐怕是其中很难的部分了，在实例中经常看到，重写代码，推翻原有架构，实际上都是没有充分思考带来的后果。代码分成的几个部分，其中Service专注于user的需求；Business专注于实现业务的核心模型；Repository专注于数据的保存。将逻辑仅存于Business中，做好接口定义，就会增加代码的稳定性和可复用性。
在看了这几篇博客之后，更加清楚地明白了架构的核心是发现问题，而目的是解决人与人之间的利益切分。