目前，我们已经是大三的学生了，但是我对软件架构的具体内涵还不是很清楚。对于“什么是架构？”的问题还模棱两可，所以我今天阅读了《架构漫谈》系列的博客，读完以后对于软件架构有了更深层次的理解。
“架构”一词最早是跟随着建筑出现的，而不是由软件工程专业产生的。为什么会产生架构呢？在博客里作者根据一个通俗易懂的故事浅谈了产生架构的原因。把一个整体切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。架构是人类发展过程中，由懵懵懂懂的，被动的去认识这个世界，变成主动的去认识，并以更高的效率去改造这个世界的方法。
每个概念实际上所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。抽象这个词代表的含义，实际上是把不同的概念的相似的部分合并在一起，形成一个新的概念。回过头来，根据架构的定义，要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。
如果把真正的问题找到，那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平。识别问题的一个最大的前提就是要搞清楚：是谁的问题。这个搞清楚了，问题的边界也就跟着确定了，再去讨论问题才有意义。切土豆的例子看似很平常，但是其内部显示着一个深奥的问题，作为软件工程师或者架构师，我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。
所有的切分调整，都是对相关人的利益的调整。当人们认识到要主动的去切分一个系统的时候，毫无疑问，我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点，这是大方向。切分的原则：必须在连续时间内发生的一个活动，不能切分。切分出来的部分的负责人，对这个部分的权利和义务必须是对等的。切分出来的部分，不应该超出一个自然人的负载。切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。
不管软件行业如何发展，模拟人的所有行为都是一个大的趋势。也就是说，软件的主要目的，还是把人类的生活模拟化，提供更低成本，高效率的新的生活。软件工程师是实现这个模拟过程的关键人物，他必须先理解人是怎么在日常生活中完成工作的，才能够很好的把这些工作在计算机中模拟出来。软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。
业务问题的本质，是业务所服务的对象的利益问题，明白了这个，就很容易搞清业务的概念和组织方式。为了能够让软件很好的跑起来，软件工程师必须理解业务所服务的对象，他们的利益所在，即业务问题。软件工程师还必须要考虑，用什么样的硬件把软件跑起来，怎样跑得好，跑得快，并且可以随着业务的流量逐渐的长大。软件因为流量增大而分拆成不同的运行单元，在不同的机器上部署所形成的架构，属于软件架构。每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。
架构师是要去平衡别人的利益，甚至会调整别人的利益的。一旦架构师是全心全意的为别人的利益服务，自然而然的架构师就拥有了强有力的影响力，肯定会是一个leader。但是只是民意上的leader是没有用的，不能完全发挥架构师的能量。架构毕竟解决的还是人的利益问题，成本越低越好，这个成本当然是长期总体成本，不是眼前的短期成本。
我们真正想快速的完成代码工作，就要克服自己对时间的恐惧，真正的去研究业务的问题，相关stakeholder的利益，把这个变成我们的习惯。写代码的时候让该出现逻辑的地方出现逻辑，让不该出现的地方不能出现。
技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。技术是为了解决业务的问题而产生的，没有了业务，技术就没有了存在的前提。有了更好的技术，效率更差的技术，就会慢慢的被淘汰，消失，一切都遵从人类的利益诉求——也就是业务。
《架构漫谈》系列的博客有九篇，篇篇是经典。对于我这种还没有走出学校，走向社会的学生来说，这些博客对我来说很重要，十分感谢作者的辛勤劳动，阅读这些博客为我将来的职业道路打下了基础 ，并为我指明了前进的方向。