从《架构漫谈》一书中阅读了解到不少关于架构的理解和实例，简单的来说架构是一种标准准则，它的存在让软件本身更具规划性，让软件内部关联，协同更高效。
是一种为了团队开发，软件未来发展而出现的一种准则。
然而要做好架构的基础就是能够正确的认识概念，能够发现概念背后所代表的问题，这样才能知道待解决的目标，这样才能为一个好架构打下基础。一般而言，作为
一名合格的架构师需要的能力就是把隐藏在问题背后的问题找出来，也就是把真正的主要的问题找出来，这也是一个架构师水平的衡量标准。
当然回到架构本身一个好的架构为的是完成一个对当前利益，参与者，功能，任务的切分，为的是让单个的个体，发挥他本身最大功能，通常来说，如果让一个人去完成
一个大型的程序，这个开发时间是无法估量和控制的，大量的开发时间会重叠，严重的影响了软件开发的效率，因此对于任务和功能的拆分就显得尤为重要，这不仅减少了
单个参与者的工作量，开发时间，也极大地提高了软件整体的开发效率，也为后期软件的维护更新提供便利，为软件开发管理提供依据。
就依据《架构漫谈》本书的结构来讲：
第一章 什么是架构？
-
必须由人执行的工作（不需要人介入，就意味着不需要改造，也就不需要架构了）
-
每个人的能力有限（每个人都有自己的强项，个人的产出受限于最短板，并且由于人的结构限制，同时只能专注于做好一件事情，比如虽然有两只眼睛，但是只能同时专注于一件事物，有两只手，无法同时做不同的事情。ps. 虽然有少部分人可以左手画圆右手画框，但是不是普遍现象）
-
每个人的时间有限（为了减少时间的投入，必然会导致把工作分解出去，给擅长于这些工作的角色来完成，见2，从而缩短时间）
-
人对目标系统有更高的要求（如果满足于现状，也就不需要进行架构了）
-
目标系统的复杂性使得单个人完成这个系统，满足条件2，3（如果个人就可以完成系统的提高，也不需要别的人参与，也就不需要架构的涉及，只是工匠，并且一般这个工作对时间的要求也不迫切。当足够熟练之后，也会有一定的架构思考，但考虑更多的是如何提高质量，提高个人的时间效率）。
第二章 如何做好架构之识别的问题
具体旨在如何一个合格的架构师需要从表面问题的背后发现本质问题。
第三章 如何做好架构之架构切分
在单个个体开发中，时间会变长，影响开发效率等问题，因此合理的划分是必要的
第四章 什么是软件
在初期，软件使用二进制编写的，从硬件到软件，成本都非常的高。随着半导体技术的进步，硬件的成本越来越低，性能越来越高，甚至出现了摩尔定律：当价格不变时，集成电路上可容纳的元器件数目，约每隔18-24个月增加一倍，性能提升一倍。软件方面，为了简化难度，开始采用汇编，进一步出现了类似于人类的语言的高级语言，这使得人类可以用类似于人的语言来和计算机沟通。软件工程师慢慢越来越多，开发软件的成本也越来越低。计算机就好像是一个只需要电，不需要休息的人，可以无休无止的工作。人们越来越愿意把原来只有人才能做的事情，交给计算机来做。结果就导致软件越来越丰富，能够做的事情也越来越多，成本也越来越低。随着软件的规模的变大，做好一个软件也变得越来越难了。早期的程序员写程序，主要是为了帮助自己研究课题。这些程序员熟练了之后，提高了自己的生产力，并发现还可以帮助别人写程序，慢慢软件就变成了一个独立的行业。
第五章 软件架构解决什么问题
1：业务问题
2：计算机问题
后几章着重于架构师的角度，一个有影响力的架构师应当具备一定的实权，只有这样，架构师对其他人的利益划分会减少很多分歧，也更容易展开工作，同时从架构的角度去看
各部分间应当存在这些责任：
-
Service就专注于user的需求，并组合Glue Code提供的服务完成需求。
-
Glue Code专注于组合business的调用，管理Business里面对象的生命周期，并且通过Repository保存或加载Business的状态
-
Business专注于实现业务的核心模型。
-
Repository专注于数据的保存，并和存储设备一一对应。