第1部分 架构与设计的原则和模式
第1章 架构与设计的流程和核心概念
很多的开发人员（不管其处于那个阶层）对架构设计特别着迷，甚至达到了痴迷和神往的地步。不过，学习编程相对而言可能是一件比较容易的事情（只要有好的学习态度和编程习惯，然后掌握一定的技术，很快就可以成为一个比较出色的开发人员），若要想练就架构设计的能力却不是那么容易。
架构，近似于艺术，有着对美的要求和对完美的追求，但它又和艺术不一样，比如：架构设计可以在软件中实实在在的体现出来，一个合适的架构会让系统有很好的灵活性和伸缩性，并且会使软件开发有良性循环；相反，一个不合适的架构则很容易导致软件在变化的需求中崩溃，甚至会让开发进入“死亡行军”的状况中。就因为如此，架构才会显得如此神秘，同时又让人难舍对它的追求。
本书将会和大家一起探讨有关架构的话题，不过，架构相关内容覆盖面很广，想要通过一本书就把它讲清楚几乎是不可能的，本书以实践角度出发，着重讲述了架构设计中可以采用的原则和模式，以及一些思想方面，希望在大家的架构之路上能够献上一点绵薄之力。
本章是全书中理论最多的一章，主要是希望大家对架构师、架构设计有一定的了解，为理解后续的章节打下基础。
1.1 正确认识软件架构
不同的人对架构有着不一样的理解。无论是在建筑行业、软件行业，还是在网络或书本上，“架构”一词有着各种各样的解释。在编程的世界中，很多对架构的解释都是从技术的层面来定义的，而且在不同的技术或平台上面，对架构的定义又不太一样，甚至有些定义和理解失去了其原本的核心意思，这就使得部分架构学习者感到迷茫。
如果认为“架构”是一个简单的实体，能够用一份文档或一张图纸来描述，那么你就错了。确实，架构师在为系统创建架构时经常要做出很多与设计相关的决定，而且会以用文档的形式记录下来，但是架构和文档又不是等同的，之所以要以文档的形式保存，主要是为了便于以后对这些设计决定进行审核和修改，并且将其作为构建软件时的约束和指导。
1.1.1 什么是架构
首先，让我们来看看架构的一个定义：
软件架构是对系统的高层视角，或者是对系统的抽象。它关注的是某些对完成这个系统有着最大帮助的方面，例如：可用性、稳定性，以及灵活性。同时，架构对如何达到这些目的给出了指导和约束。
如果要用最简单的方式来理解上面的定义，可以这样说：软件架构就是软件系统的一张蓝图。
下面我们用一个比较浅显的类比来说明这个“蓝图”的含义。
相信大家对冶金行业中的“浇筑”或多或少有一些了解。浇筑就是把液体材料倒在一个有着特定形状的沙模中，然后等液体冷却之后得到想要的产品或特定形状材料的过程。在这个过程中，盛放液体的沙模引导着液体慢慢成形，最后得到我们预想的结果。
其中，有一点要注意的是，沙模的特性（比如形状和大小）和倒入其中的液体是没有任何联系的，换句话说：沙模和液体是完全分离的，但是沙模又必须和液体在一起才能生产出所要的产品。
架构就好比上面例子中的沙模，软件项目就好比用于浇筑的液体。正如浇筑一样，架构引导着项目，最后得到了我们想要的结果。同时，我们也可以得出：软件的架构和实现这个系统的代码是没有很严格的关系的，这也就是我们常说的架构是平台无关的。架构可确保开发的过程在一定的限制或规则下进行。
对于沙模来说，如果没有浇筑液体的存在，它基本就没有任何作用；架构也是立足项目的特定需求来设计的！
本文转自yanyangtian51CTO博客，原文链接： http://blog.51cto.com/yanyangtian/745261
，如需转载请自行联系原作者
