阅读笔记——架构漫谈

　　今天阅读了王概凯老师的架构漫谈，里面主要讲解了他对架构等概念的理解。

　　什么是架构？

　　架构就是根据要解决的问题，对目标系统的边界进行界定，并把目标系统按某一原则进行切分，减少解决问题的成本，并对切分出来的部分建立沟通机制，使得这些切分出来的部分能组装成一个整体。架构的产生就是因为早期个人同一时刻只能做有限的事情，但是一个人完成的生产远远不能满足自己的需求，于是就产生的集体，出现了集体就会进行分工，分工就需要让集体里的每个个体都需要能发挥自己的优势，产生最大的利益，由不同的却色来完成这些分工，并建立不同部分互相沟通的机制，使得这些部分能有机的结合为一个整体，并王城整体所需要的所有活动，这就是架构。

　　架构的产生是为了更高效的解决人的问题，但是高效解决问题的前提一定要搞清楚问题的主体，这样才能确定问题的边界。架构师都要有这个自觉：发现问题永远都比结局问题来的更加重要。

　　发现问题之后就是解决问题，就要对问题进行切分已达到更高效的解决问题。那么要如何切分呢？首先我们要清楚一点，切分就是利益的调整，所有的切分调整都是对相关人的利益的调整，因为每个人的骨子里都是维护自己的利益。所以切分的原则就是根据实际情况，按层切分，使得每个stakeholder的权责对等，每个stakeholder为自己的利益负责。但是要注意，切分时不能违法人性，所有的架构分析都应该是形成树状的，不应该变成有向图，更不应该变成有向图。

　　回到软件，我们首先要理解软件的概念，王老师认为软件就是人类日常生活的模拟，虚拟化。随着人类生活的发展，软件的规模也越来越大，做好一个软件已经也变得越来越难，于是，程序的完成也变成了有许多不同角色的人共同合作来完成。软件架构的出现也是同样的。一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。这个背后的动力也是一样的，就是提升参与的人的利益，降低成本。导火索也是软件工程师的任务太重，我们需要把很多工作拆分出来。拆分的原则也是一样的，如何让权责一致。同样，这个拆分也是需要组织架构的调整，来保证架构的落地。软件架构是为了更好的开发软件，而软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。这与前面提到的架构是相同的。

　　后面王概凯还谈到了从架构的角度看如何写好代码，他提到代码可明确的拆分为两个不同的责任：表达业务逻辑的代码（Domain Model），对用户提供分并保存业务逻辑运行结果的代码。就是业务处理的代码和用户交互结果的代码，所有的软件都是这个样子的，处理业务，响应用户的请求。从架构的角度来看代码，我们想要真正快速的完成代码工作，就要克服自己对时间的恐惧，真正去研究业务的问题，相关stakeholder的利益。让逻辑出现在逻辑该出现的地方，一旦不该出现的地方出现了逻辑，就要意识到这个地方是个坑。正确研究业务的问题，确定问题的边界，让开发变得清晰明了。

　　最后就是技术，业务和架构的关系。在日常的开发过程中，经常会有人讨论架构而实际是在讨论技术，甚至在很多人的概念里，架构和技术实际上是等同的。学会了几种技术，就任务自己是架构师，觉得学习的技术越多，就觉得自己的水平越高。我自己以前也是这样认为的。王概凯认为这实际上对几种很不负责任，我们要清楚，任何技术都是为了解决某种问题而存在的，学会了技术，并不代表我们就能解决问题，习得的技术的多少只是自己解决问题的手段多了一点。我们面对问题时，需要知道采用那种技术更好，这样我们习得的技术才用到的刀尖上了。对于业务和技术，我们要清楚，技术是为了解决业务问题而产生的，技术与业务相伴相生，而架构就是不断的更新解决业务问题的技术。所以架构师要具备准确采用什么技术的能力，考虑长期的成本和利益。