【IT168 技术文章】

    从这一篇开始，我们将会进入另一个不同的主题，和前面所讨论的模式专注于组织、过程、方法不同，以后介绍的模式更偏重于设计。但是过程、方法的影子依然在我们的讨论中隐约可见。

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

    Context

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

    Problem

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

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

    Solution

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

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

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

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