对于大三下学期的我来说软件架构师这门职业仅限于听说过，连具体是干什么的都不了解。这次读了资深架构师王概凯Kevin执笔的系列专栏《架构漫谈》，令我对软件架构这一门课程以及软件架构师这门工作有了深入的认识与了解。
软件架构正是这学期我们要学习的一门课程，其中重要的两个字 架构 ，只有我们真正的了解这个词语才能理解什么是软件架构。架构：对目标系统的边界进行界定，并对目标系统按某个原则的进行切分，之后再将切分出来的部分设立沟通机制，进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。具体的，我们还需要理解概念这一词语，就像老师上课举的书中的例子，什么是桌子？什么是茶杯？只用表面的外观形态形容就可以了吗？当然是不够的。所以做架构的时候，不同角色的沟通会出很多问题，那么结果也就可想而知了。不同的人对于同一事物的理解是不一样的，所产生的概念当然是也是不同的。看完第二篇之后我对概念的理解就是，根据它的外表来思考它的作用，根据其作用再找出概念对它进行描述。做好架构首先需要做的就是识别出需要解决的问题。一般来说，如果把真正的问题找到，那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平。软件开发工作者的时间分配也可以看出，大家大部分时间花在讨论解决方案和实现的细节上，基本都不会花时间去想“问题是什么”。或者即使想了一点点，也是一闪而过，凭自己的直觉下判断。只有真正投入思考问题是什么的工程师，才可能会真正的成长为架构师。这是文章中给我印象特深刻的一句话，这就是一般的软件开发人员与真正的软件架构师之间的差距吧。
就像我之前在一个博客上看到的一样“软件开发管理是对大脑的管理，不关注大脑的自身“情感”是要吃苦头的”。做好架构切分是做软件架构中重要的一环，当人们认识到要主动的去切分一个系统的时候，毫无疑问，我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点，这是大方向。把握住了这个大方向可以使我们在成为软件架构师的这条路好走很多。弄明白什么是架构怎么做好架构之后，我们就应该开始理解软件架构，随着软件的规模的变大，做好一个软件也变得越来越难了。早期的程序员写程序，主要是为了帮助自己研究课题。这些程序员熟练了之后，提高了自己的生产力，并发现还可以帮助别人写程序，慢慢软件就变成了一个独立的行业。程序从早期由一个人完成，也逐渐变成了由很多不同角色的人共同合作来完成。以下讨论的前提，都是基于帮助别人写程序，多人合作的基础上的。结论对于单人为自己写程序也适用。换句话说就是尽可能的减小成本，提高效率。学会换位思考，站在用户的角度把问题简单化。伴随着社会时代的发展，软件扮演者越来越多的身份，灵活理解和运用这些身份，才能更为优秀的进行软件架构。
软件架构师另一个重点，我们需要知道在为谁解决什么问题？业务问题的本质，是业务所服务的对象的利益问题，明白了这个，就很容易搞清业务的概念和组织方式。再次强调一下，有了软件，可以降低业务的成本，没有软件的情况下，业务是一样跑的。同时，在有限的时间下，软件工程师毫无疑问无法一个人去完成这么多事情，那么我们需要把所做的事情列出来，进行分析。
软件架构师角度引出的，对于代码的编写，软件实际上是对现实生活的模拟、虚拟化。这是一个非常重要的前提，直接决定了我们的代码应该分为几部分。结合每个部署单元所承担的责任，可以明确的拆分为两个不同的责任：表达业务逻辑的代码、对用户提供访问并保存业务逻辑运行结果的代码。以上就是我对这九篇博客的一些浅薄收获了。
在浏览相关文章时候看到一个五视图架构法感觉还是很深刻的:
