正如文章开篇所说的那样：一直以来，在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。那么究竟什么是软件架构呢？其实，把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。也就是根据要解决的问题，对目标系统的边界进行界定，并对目标系统按某个原则的进行切分，切分的原则要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间，并对这些切分出来的部分，设立沟通机制，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
按照架构的定义，做好架构首先需要做的就是识别出需要解决的问题，通俗的说，找出问题的主体，是做架构的首要问题，只有明白了问题的主题，我们才可能真正的认识问题是什么。这是因为问题的主题是问题的隐含边界，边界不确定下来，问题就是不确定的，一旦确定了主题，剩下的就是去搞明白主题有哪些问题。识别出是谁的问题之后，会发现，在大多数情况下，问题都迎刃而解，不需要做额外的动作。但是总有一部分确实是有问题的，需要做调整，那么就必须要有所动作，做相应的调整，而这个调整就是架构的切分。我们都非常的清楚，所有的切分调整，都是对相关人的利益的调整。实际上切分的过程就是建模的过程，每次对大问题的切分都会生成很多小问题，每个小问题就形成了不同的概念。
我们都是软件工程系的学生，但是我敢肯定的，没有一个人可以准确说出什么是软件。学了这么多课程，我们了解软件的历史吗？其实，软件的历史，实际上可以说是用机器模拟人的历史，不知道有人意识到没有，我们都有意无意的在计算机上模仿人类的行为。有了软件之后，实际上，我们是把我们日常生活中所有的事情，包括我们自己本人都一起虚拟化到了计算机中，而人则演化成了，通过计算机的输入输出设备，控制计算机中的自己，来完成日常的工作，以及与其他人的沟通。也就是说，软件一直以来的动力，始终都是来模拟人和这个社会的。
阅读了这么多，我们知道了软件架构实际上包括了代码架构以及重载代码运行的硬件部署架构。我们经常会听说，重写代码，推翻原来架构，重新设计等等说法，来说明架构的进化，这实际上就是当初为了完成任务，没有充分思考所带来的后果。我们已经知道，软件实际上是对现实生活的模拟，虚拟化，这是一个非常重要的前提，直接决定了我们的代码应该分成几部分，结合每个部署单元所承担的责任，可以明确地拆分为两个不同的责任：其一，表达业务逻辑的代码，很多人把这部分叫做Domain Logic,或者叫Domain Model。这部分实际是来源于生活的，必须保持和现实生活中的切分一致，并非人为的抽象而成。其二，对用户提供访问并保存业务逻辑运行结果的代码。计算机的状态保存有一个缺陷，本机保留业务运行结果有很大的问题，一般都在外存储设备上保存，也便于扩展。众所周知，service的代码是最复杂的，需要服务于三方，为了把这三方的变化对service的影响降到最低，对于service进一步的拆分为三个部分，他们分别是Service、Glue Code、Business,让每一个部分都能够独立的变化，这样这三方的变化就不会产生连锁响应，降低成本。
阅读完架构漫谈，我对软件体系架构这门课有了充分的了解，也对架构的概念有了清晰的认识，这对于我以后的学习起了很大的帮助。
posted on
