本文只是个人阅读架构漫谈博客后的一些个人理解，有些地方可能谈论的略显浅薄，欢迎读者提出不同意见以及不足的地方，共同交流进步。
想要了解架构师的是做什么工作，以及如何去工作的，就必须要清楚地了解架构这一概念以及它的衍生知识。只有对架构有了足够的理解，明确的理解架构是为谁解决问题的以及架构产生的环境以及特性，才能在此基础上不断地总结经验，对软件架构进行深入研究，逐步走向架构师这一角色。
架构漫谈（一）中是如此定义架构的：把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。从这个定义中可以清楚地看出，我们需要在工作时，需要根据不同的环境和问题本身的特性进行分析，对该工作系统提出一个边界限定，在这个边界内对问题进行合理划分，即对限制条件进行分析将现有资源进行最符合实际条件的利用。但是过程中要注意系统的完整性，切忌各部分之间朝着不同方向发展，要建立一种适合的机制，将各部分合理沟通，以便于合并总结，完整的解决最初提出的问题。
当然了，仅仅了解架构的基础知识还不能称之为架构师。架构漫谈（三）中谈到，做好架构首先需要做的就是识别出需要解决的问题。一般来说，如果把真正的问题找到，那么问题就已经解决了 80% 了。虽然这个比例不是特别准确，但是显示出了识别问题这一能力对一个软件架构师的重要性，想要准确的认识问题，首先要了解这是谁的问题，从问题暴露的点，一点点去溯源查找，一定会有所收获，当你清楚的了解问题的主体，就能准确的确定问题的边界。一旦确定了主体，剩下的就是去搞明白主体有哪些问题，这一方面就比较直接宽泛了，需要我们根据实际的环境和对象去具体分析。在此之后我们就可以对系统进行切分调整了，这是因为在工作过程中，会出现某个或者某些利益相关人的权利和义务不对以及某个或者某些利益相关人负载太重的情况，切分自然而然的产生了。当然切分也需要遵守原则：必须在连续时间内发生的一个活动，不能切分；切分出来的部分的负责人，对这个部分的权利和义务必须是对等的；切分出来的部分，不应该超出一个自然人的负载；切分是内部活动，内部无任怎么切，对整个系统的外部应该是透明的。
讨论完架构的相关概念，就应该把软件与架构进行连接了。在硬件上编写出的程序，就是软件，是用来控制硬件的行为的，这是软件的定义。随着软件发展，人们越来越愿意把原来只有人才能做的事情，交给计算机来做。结果就导致软件越来越丰富，能够做的事情也越来越多，成本也越来越低。实际上，我们是把我们日常生活中所做的事情，包括我们自己本人都一起虚拟化到了计算机中。一开始人们是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，由此演变成了不同的软件架构。那么软件架构的产生能够为我们解决谁的问题，又能解决怎样的问题呢？如前所述，软件实际上就是把现实生活模拟到计算机中，并且软件是需要在计算机的硬件中运行起来的。要做到这一点需要解决两个问题：具体的现实生活状态下，没有软件的时候，所解决的问题的主体是谁，解决的是什么问题，是如何解决，如何运作的；如何把现实生活用软件来模拟。
接下来我将会对架构师这一职业提出个人的一些理解，想成为架构师，首先要突破自己的防线，要把目标和视野放大，不要仅仅满足于解决自己的问题，要超越对时间的恐惧，专注的思考并且解决别人的问题。架构师是要去平衡别人的利益，甚至会调整别人的利益的。必须是一个组织的领导人，有权利调动这个组织的架构，才能够更好的发挥架构师的作用，更好的把利益的调整落到实处。架构师需要在工作过程中将对架构的思考落地，细化到代码中去，明确的可以拆分为两个不同的责任：表达业务逻辑的代码；对用户提供访问并保存业务逻辑运行结果的代码。在对代码进行分析后，要清楚地理解技术、业务和架构之间的关系。架构师应该承担起解决业务问题的这个角色来，专注于Business Domain和软件本身的架构，让技术人员致力于为业务在计算机中跑起来而努力。只有把这两者很好的结合起来，才能更好地完成业务的目标，才会让软件更好地服务于大家。最终一定会得到一个很好的软件架构，令软件开发团队和业务部门都能够很好地开展工作并降低成本。
总之，架构漫谈给了我很多启示，让我对架构有了深刻的理解，同时认识了架构师这个职业，感受颇深。