我们可以了解到在图的背后隐藏着的需求：系统需要支持多种用户界面，包括为普通用户提供的HTML界面，为无线用户提供的WML界面，为管理员提供的Swing界面，以及为B2B业务设计的WebService界面。这是系统最重要的需求，因此，系统的设计者就需要确定一个稳定的架构，以解决多界面的问题。相对于多界面的问题，后端的业务处理逻辑都是一致的。比如HTML界面和WML界面的功能并没有太大的差别。把处理逻辑和界面分离开来还有额外的好处，可以在添加功能的同时，不涉及界面的改动，反之亦然。这就是我们在第二篇中提到的耦合度的问题。
MVC模式正可以适用于解决该问题。系统使用控制器来为业务逻辑选择不同的界面，这就完成了MVC架构的设计思路。在架构设计的工作中，我们手头上有模式这样一张好牌，有什么理由不去使用它呢？
抓住重点
在架构设计一开始，我们就说架构是一种抽象，那就是说，架构设计摒弃了具体的细节，仅仅抓住软件最高层的概念，也就是最上层、优先级最高、风险最大的那部分需求。
我们考虑、分析、解决一个问题，一定有一个渐进的过程。架构设计就是解决问题其中比较早期的一个阶段，我们不会在架构设计这个阶段投入过多的时间（具体的原因在下文会有讨论），因此关键点在于我们要能够在架构设计中把握住需求的重点。比如，我们在模式一节中提到了分布式系统和交互系统，分布和交互就是这两个系统的重点。那么，如果说我们面对的是一个分布式的交互系统，那么，我们就需要把这两种特性做为重点来考虑，并以此为基础，设计架构。而我们提到的宠物商店的范例也是类似的，除了MVC的架构，还有很多的设计问题需要解决，例如用于数据库访问的数据对象，用于视图管理的前端控制器，等等（具体使用到的架构模式可以访问sun的网站）。但是这些相对于MVC模式来说，属于局部的，优先级较低的部分，可以在架构确定后再来设计。
架构设计和领域专家
一个架构要设计的好，和对需求的理解是分不开的。因此在现实中，我们发现业务领域专家凭借着他对业务领域的了解，能够帮助开发人员设计出优秀的架构来。架构是需要抽象的，它是现实社会活动的一个基本模型，而业务领域的模型仅仅凭开发人员是很难设计出来的。在ERP的发展史上，我们看到MRP发展为MRPII，在发展到闭环MRP，直到发展成为现在的ERP，主要的因素是管理思想的演化，也就是说，对业务领域的理解进步了，架构才有可能进步。
因此，敏捷型架构设计的过程中，我们也非常强调领域专家的作用。
例3：信贷系统
在一个银行的信贷帐务处理系统中，我们应该如何把握最初的架构思路呢？从需求上来看，这个信贷帐务处理系统有几个特点：
它不是一个单独的系统，它需要和外部的其它系统交互，例如信贷业务系统、网上银行、数据仓库系统等。
在所有的需求中，最复杂的就是它的利息计算的需求，它要求能够支持多种的利息算法。
因此，我们的架构设计首先是从系统的全局环境开始考虑。其它系统和该系统的关系如何，应该如何设计系统间的接口。通过需求的调研，系统的接口分为4类：
和企业外部系统的接口。信贷系统需要连接到人民银行的系统。
和企业内部系统的接口。信贷系统需要能够为数据仓库系统和网上银行系统提供数据。
和平级系统的接口。信贷系统需要从平级的帐户、资金、财务系统中取数据，并向帐户、押汇系统发送数据。
具体的实现策略并不在我们的讨论范围之内，但是可以看到，架构策略的制定是以需求为基础的。我们可以把这部分的需求归纳为技术架构或平台架构。
然后是利息算法的问题，我们经过统计，目前的利息计算方式有四种，可预见到的还有两种。在一开始的阶段，我们并不需要考虑具体算法的实现，但是我们需要考虑算法的实现框架，因此我们很自然的想到Strategy模式可以胜任这一工作，把不同的利息算法封装起来。而我们的工作重点也就转到定义利息算法的接口问题。通过分析、比较多种利息算法，我们定义了一个最初始的算法接口，然后由不同的利息算法来实现算法接口。虽然，这个接口目前还不是很完整，但是它会在接下去的开发过程中慢慢的完善起来。这部分的需求属于业务架构的一部分。
考虑到系统的结构非常的复杂，因此在系统结构的处理上，我们采用了层模式做为系统的基本结构。此外，在每个层，我们还定义了几个子模块来处理特定的问题。这样，我们就可以将复杂的功能有序的组织起来。
经过上述的分析，我们对系统的架构有了一个简单的认识，但是还没有结束，一个架构应该包括系统的各个基本部分，因此，我们还要考虑票据处理、报表、帐务处理等环节，但是一开始就考虑周详，这要花费大量的时间，因此我们只是简单的定义了一个原始的架构，然后在后续的开发过程中把这个架构完善起来。
您的位置：
