架构漫谈（王概凯）后五章读后感
本文是漫谈架构专栏的第五篇，作者将会从自己的认知角度再次反思什么是软件，文中作者探讨了软件发展火热的根本原因以及软件扮演的角色等问题。如前几天一位架构师所说，我们并不缺架构实践，而是缺少对于架构的反思，希望这系列文章能帮你重新理解架构，重新认识软件。
前面通过四篇文章，把什么是架构，如何做好架构等必要的概念澄清了一下。这些概念对于在各种不同的领域都应该也是有用的，需要读者自行思考，并应用到自己所在的领域中。在这篇文章开始，我们用同样的思考，来看看软件是怎么回事，以及如何运用架构思维，更好的设计和实现软件。
冯诺依曼结构，图灵机，以模拟人为目标
成本为王
软件扮演的角色
仍然是为了提升人类自己的利益，解决人类自己的问题。
软件实际上就是把现实生活模拟到计算机中，并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题：
一、业务问题
二、计算机问题
所以当我们说软件架构的时候，我们一定要讲清楚，究竟说的是部署的架构，还是代码的架构。软件架构的落地，需要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。
另外很多人讲，架构是进化出来的。架构实际上是在量不断的增大，超过了单台服务器的容量，逐渐的分拆，同时导致超过单个人员的能力，工作人员不断的增多，工作内容不断的分拆形成的。这本身就是架构的意义所在。不管怎么分拆，所达到的目标没有任何变化，就是完成业务在计算机中的虚拟化。
在第七章作者描述了架构师
的前提条件、
权利和义务、技术
让我队软件架构师有一个初步的了解
软件实际上是对现实生活的模拟，虚拟化。这是一个非常重要的前提，直接决定了我们的代码应该分为几部分。结合每个部署单元所承担的责任，可以明确的拆分为两个不同的责任：
- 表达业务逻辑的代码。很多人把这部分叫做 Domain Logic，或者叫 Domain Model。这部分实际是来源于生活的，必须保持和现实生活中的切分一致，并非人为的抽象而成。
- 对用户提供访问并保存业务逻辑运行结果的代码。计算机的状态保存有一个缺陷，本机保留业务运行结果有很大的问题，一般都在外存储设备上保存，也便于扩展
- 在架构漫谈的最后一章作者阐述了什么是技术、
技术与架构，以及与业务之间的关系、
架构师和技术人员的关系
重新发明轮子
当现有已经存在很多技术，而这些技术却和我们所要解决的问题并不是那么直接对应的时候，我们就需要有意识的组织和识别不同的技术，来实现业务的目标。这个时候组织的方式有很多种，其中成本最低的方法就是按照要达成的目的和当前的问题，从上到下进行架构分拆。分拆出来的更细粒度的问题，分解到不同的人来进行解决，就形成了业务架构和组织架构。解决这些问题就需要组合很多不同的技术，那么应该采用哪些技术？还是自己重头实现一个？ 自己实现一个—这就是很多人所谓的重新发明轮子。以下试着分析一下：
- 当技术所解决的问题和分拆出来要解决的问题，完全匹配的时候，这是最完美的。比如需要提供 web 要访问的 service，很多 MVC 的 framework 就可以很好的满足这一点。而这个时候如果非要自己实现一个，很有可能就是重新发明轮子。
- 当技术所提供的能力远远超过需要解决的问题时，往往掌握技术和维护技术会成为瓶颈。因为越复杂的技术，成本越高。如果自己实现一个仅仅是解决当前问题的方案，可能成本反而更低。这也是为什么很多大型的互联网公司不断地开源出来自己的技术的原因。而这些技术对于我们来说是否适用？他们原本是用来解决谁的问题的？什么问题？如果不清楚这些，就冒然采用，可能会导致更高的成本。
- 当技术所提供的能力和我们所要解决的问题部分匹配时，还是要看成本。比如当我们需要一个锤子的时候，手边正好没有，但是却有一只高跟鞋，勉强也可以替代锤子。但是长期来看，这么用不划算，因为高跟鞋的价格比锤子高很多，耐用性差很多，维护成本也高很多。
所以，准确识别采用什么技术的能力，也是架构师所要具备的能力之一。考虑的主要因素也是长期的成本和收益。
