在本周的课程学习当中，老师还让我们课后阅读了《架构漫谈》，我也从中学到了许多的知识内容，对课堂的学习有很大帮助。
在对书籍的阅读当中，我简单了解到了架构的含义，对于架构有了更深的了解。把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。
要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。架构实际上解决的是人的问题，而概念是人认识这个世界的基础，自然概念的认识就非常的重要。做架构的时候，很多时候都是在一个新的领域解决问题，必须要快速进入并掌握这个领域，然后才能够正确的解决问题。
做好架构首先需要做的就是识别出需要解决的问题。通常我们大家都把大部分的时间花在了讨论解决方案和实现的细节上，基本上都不会花时间去思考“问题是什么”，但是明白问题是什么对于我们做什么至关重要。当前的所有概念基本都有一个很大的问题，那就是缺乏主语，但是我们大家却都心照不宣的忽略了这个主语，在沟通的时候也都想当然地认为大家都懂得对方说的主语是谁，结果其实谁也不清楚主语是谁。最后的结果是什么呢，每个人都做了很多工作，每个人都认为自己做的是对的，因此没有一个人对结果满意。因为真正的问题没有被发现，自然也就没有被解决，那么后续还得收拾残局，还要继续解决问题。事实上自己的工作并没有完成，反而更多了。所以识别问题的一个最大的前提就是要搞清楚：是谁的问题，只有把这个搞清楚了，问题的边界也就跟着确定了，再去讨论问题才有意义。在识别出是谁的问题之后，我们就会发现，大部分情况下的问题都迎刃而解，不需要做额外的动作。
架构的出现是有原因的。一开始是懵懵懂懂的去写软件，后来慢慢的就有意识的去切分，演变成了不同的架构。软件的本质，其实就是通过把人类的日常工作生活虚拟化，减少成本，提升单个人员的生产力，提升人类自己的利益。软件工程师的职责在这个浪潮中，不堪重负，自然而然就分拆为不同的角色，形成了一个独特的架构体系。当我们说软件架构的时候，一定要清楚是部署的架构，还是代码的架构。软件架构的落地，需要软件的组织架构和流程来保障，离开了这个，软件架构是一句空话。架构实际上是在量不断的增大，超过了单台服务器的容量，逐渐的分拆，同时导致超过单个人员的能力，工作人员不断的增多，工作内容不断的分拆形成的。这本身就是架构的意义所在。不管怎么分拆，所达到的目标没有任何变化，就是完成业务在计算机中的虚拟化。
软件架构过程可以明确地拆分为两个不同的责任：其一，表达业务逻辑的代码，很多人把这部分叫做Domain Logic,或者叫Domain Model。这部分实际是来源于生活的，必须保持和现实生活中的切分一致，并非人为的抽象而成。其二，对用户提供访问并保存业务逻辑运行结果的代码。计算机的状态保存有一个缺陷，本机保留业务运行结果有很大的问题，一般都在外存储设备上保存，也便于扩展。众所周知，service的代码是最复杂的，需要服务于三方，为了把这三方的变化对service的影响降到最低，对于service进一步的拆分为三个部分，他们分别是Service、Glue Code、Business,让每一个部分都能够独立的变化，这样这三方的变化就不会产生连锁响应，降低成本。这就是软件架构的本质思想，由于我还为进行过项目的架构的使用，对架构如何在项目中实现还不是很明白。
该怎么处理业务、技术还有架构的关系也是一门学问，技术总是在人类解决对业务的要求不断提高的情况下产生，目的也是为了获取更大更好的利益。所以，准确识别采用什么技术的能力，也是架构师所要具备的能力之一。通过对这本书的阅读，从整体的角度对软件架构有深层侧的理解，这是在进一步进行实际项目的开发中应具有很重要能力。
在我们的学习当中，肯定会接触到很多关于架构的知识，只有不断的接触和理解，才能更好的掌握知识和技能，为以后的工作增加更多的本钱。