架构愿景是一个很简单的模式，在软件开发中所占的时间也很短。但是这并不意味着架构愿景不重要。相反，它会是设计过程不可或缺的一环。

Context

在单次的迭代开始阶段，我们已经收集好了单次迭代的需求。

Problem

架构和分析设计是密不可分的，有时候很难说得清楚架构的定义，但架构应该能够描述软件的整体。架构包括了软件的各个方面，但是每一个设计细节总是需要单独考虑，这时候就会出现设计细节之间、以及设计细节和架构之间的不一致。

架构设计的各个部分之间的设计冲突是很容易发生的。发生的概率及频率和团队的规模成正比、和沟通的频度及效果成反比。在很多次的项目开发过程中，我们发现了多处的相同功能的代码，原因是代码的作者并不知道别人已经实现了这个功能了。这可能只是浪费了一点精力，可如果不同模块间的设计冲突导致了软件无法正常运行的时候，我们就需要坐下来好好的审视，究竟发生了什么。

Solution

我们需要建立一个架构愿景。架构愿景应该能够提供软件全局视图，包括所有的重要部分，定义了各个部分的责任和之间的关系，而且还定义了软件设计需要满足的原则。而这个架构愿景的设计，应该是满足源自需求模式的，也就是说，部分的划分和部分的设计，都是根据需求而进行的。同时，架构愿景应该要能够满足架构的其它各种特点，例如简单、可扩展性、抽象性。简单来说，我们把架构愿景当作是一个mini的架构设计。

由于我们是在单次的迭代中讨论架构愿景，因此从整体上考虑，架构愿景是也是在不断的变化的。这是很自然的，因为架构愿景代表了架构的设计，架构愿景的演进代表了架构设计的演进。

架构的愿景是相对于一个范围来说的，在一个特定的软件功能范围之内，谈架构愿景才有实际的意义，例如针对软件的全局或某个子模块。在这个特定的范围中，订立了架构愿景之后，这个范围内的所有设计原则将不能违背架构愿景。这是非常重要的，是架构愿景的最大的用处。有了这样的保证，我们就可以保证设计的一致性和有效性。任何一项设计的加入，都能够融入到原先的架构中，使得软件更加的完善，而不是更加的危险。

当然，要做到这一点并不是一件容易的事情。特别需要指出的是，架构愿景模式仅仅是实现该目的的一条道路，并不是一个充分条件。如果在设计中愿景不能够贯彻其意志，或是愿景制定本身就存在问题，那么要想达到上述的效果，几乎是不可能的事情。此外，该模式仅仅只是达到该目的的第一步，我们在接下去的模式中会发现还需要很多方面的配合。

架构愿景的层次

我们根据架构适用范围的不同，把架构愿景分为几个类别讨论：

软件全局

软件全局的架构是我们所最关心的，因此也会花费最多的笔墨。

软件全局中的架构愿景一般很难具体化到代码级别，其实你会发现，就算是具体化到了代码级别，也会因为实际中存在的问题，导致代码没有太多的价值。因此，为软件全局设置的架构愿景可以以原则、或是模式名的方式体现，并用自然语言或伪代码描述。例如，可以为一个系统规定三层架构作为其愿景，并指出三层的分类原则。注意，我们需要指出分类原则，否则规定三层架构并没有太大的意义，因为三层架构随着实现平台的不同、开发人员的不同而有很大的差异，如果不能够规定一个可操作的规范，那么愿景是没有意义的。在Java环境下，我们可以这样说：

"客户端采用前端浏览器界面，业务逻辑采用servlet，配合JSP编写，浏览器到服务器的数据采用集中处理，具体的方法是在业务逻辑和前端浏览器之间采用Front Control模式，接受前端浏览器传送过来的数据，并指派给相应的业务逻辑处理。数据的合法性检验分为两个部分：和业务逻辑无关的基本合法性验证在前端使用Java Script处理，和业务逻辑相关的合法性验证在业务逻辑层处理，可以使用一个集中的servlet专门处理错误情况。"

而在Windows环境下，我们知道三层结构的分界和Java中的并不相同（关于这一点，下一篇的文章中将会有详细的描述），我们可以在业务逻辑层或显示层直接操纵数据，非常的方便，因此，在Windows中的架构愿景的描述又不一样。另外，在非面向对象的环境中，在分布式的环境中，在Lotus Notes的环境中，其架构的描述都不一样。

注意到，架构愿景的制定是根据不同的应用环境而变化的，这一点我们在文章的一开始就强调过，这里又出现了相同的问题。我们可以通过一个简单的例子来加深对这个问题的理解。在Java的环境下，特别是J2EE的环境下面，经典的设计思路是把数据库的一张表视作一个类，表中的每一行都是这个类的一个具体的实例，表的每一个字段对应了类的一个变量，类一般支持Find方法，来获取数据不同的实例。这是一种很自然的设计思路，而且可以通过CMP等技术来简化设计的繁琐步骤。可是，在Windows环境下，相信没有多少人会这么做。常用的处理方法是使用记录集（RecordSet）的方式，也就是说针对一组的记录来进行操作，而不是单个的记录。这些记录可以是跨表的（使用SQL的连接），也可以是单表的。由于Windows环境下大多数的编程语言都能够支持记录集方式，因此编写基于记录集方式的程序是相当简单的。当然，我们也可以采用J2EE平台的编程方式，但是会导致编程量的激增，同时也难以达到预计的效果。这种平台的差别导致了架构愿景的差别。

此外，我们注意到我们对架构的描述其实还是不够仔细，这是非常正常的，因为随着开发的深入，我们会不断的完善架构的描述。例如，我们可以写出Front Controll的类框架，写出主要的几个Servlet，以及他们之间的关系。这个时候，使用UML类图会是一个不错的选择，实际上，我非常推崇在架构设计中大量的使用类图。不过在实际的运作中，每个软件团队大多数都有自己熟悉的架构设计思路，使用何种工具并不是主要的问题。