在阅读了资深架构师王概凯的九篇架构漫谈以及结合自己对以前架构的一些理解后，在架构这方面自己有了不一样的体会。
先从最根本开始，为什么会出现架构，架构是怎么出来的。王概凯在漫谈中也提到了试想人类早期阶段，每个人的生活起居都是靠自己一个人来打理的，不管是什么事情都是一个人在做，不管是简单还是复杂。实际呢，这种只靠一个人的精力的作业的效率是非常低的。有时候不仅做不完，而且还做不好，会导致个人生活变得越来越糟糕。所以到后来人们为了能好的生存下去，就形成了群居生活，形成了部落，大家一起，各自分配任务，各自做着自己擅长的事情。使得整个人群的生产力和抵抗力都得到了很大的提升，进而人们能够继续的生存下去。
对于架构来说也是这样，起初一个人做项目的时候，完全不需要什么架构，因为根本没什么意义。到了后来为了提高效率，并且有了合作开发的概念。逐渐出现了架构这一概念。通过将一个整体切分成不同的部分，并且由不同的人不同的角色来完成这些分工，然后通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，最后完成这个整体所需要的所有活动。
我们要认识到，架构实际上解决的是人的问题。我们人需要什么，应该用什么东西来满足我们的需要，通常不只有一个东西能解决我们的需求，也不只有一个需求用到同一个东西，根据我们需求的不同，相同的东西可能会有不同的用法。我们必须要有这样一个概念，就是我们是为了在解决一个具体的问题的前提下，才需要能解决我们问题的框架。意思就是我们要首先知道这个框架解决了我们什么问题，然后才开始有针对的学习它。不要一味的为了学习框架而学习框架，盲目的学习很多很多的框架，这样会导致你不仅浪费了时间，而且在今后的几年中如果你不用其中的某个框架，你肯定会忘记，这样来说是非常得不偿失的。
当我们去解决一个问题的时候，我们一定要先把问题搞清楚。很多软件开发者的时间往往会用在讨论解决方案和实现的细节上，基本不会花什么时间去想“问题是什么”。或者即使想了一点点，也基本都是一闪而过，然后凭借自己的直觉去下判断。而成为架构的一个标准认真思考问题的本质是什么，要主动去思考根源，究竟“问题是什么”。正确认识和理解“这是谁的问题”和“有什么问题”这两个问题。
对于软件架构，如同前面描述的架构的定义，软件架构的出现也是同样的。一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。这个背后的动力也是一样的，就是提升参与的人的利益，降低成本。导火索也是软件工程师的任务太重，我们需要把很多工作拆分出来。拆分的原则也是一样的，如何让权责一致。同样，这个拆分也是需要组织架构的调整，来保证架构的落地。 软件实际上就是把现实生活模拟到计算机中，并且软件是需要在计算机的硬件中运行起来的。 它解决的是我们的业务问题和计算机问题。当我们说软件架构的时候，我们一定要讲清楚，究竟说的是部署的架构，还是代码的架构
软件架构实际上包括了：代码架构，以及承载代码运行的硬件部署架构。实际上，硬件部署架构最终还是由代码的架构来决定。因为代码架构不合理，是无法把一个运行单元分拆出多个来的，那么硬件架构能分拆的就非常的有限，整个系统最终很难长的更大。