注：我们把中间产物定义为为了实现跨边界的沟通而制定的文档、模型、代码。例如设计文档、数据模型等。参考RUP的Artifact。 评判软件成功的标准有很多，对于敏捷方法论来说，成功的标准首先在于交付可用的软件。为了保证软件的可用性，最重要的就是做好需求。做好需求的方法有很多(参见拙作需求的实践)，但这并不是我们讨论的主题。对于我们要开始的架构设计的工作来说，从需求出发来设计架构，这就是保证软件可用性的一个基本的保证。
Context
我们如何开始我们的架构设计工作?
Problem
我们在进行架构设计的时候，往往主要考虑的都是平台、语言、开发环境、数据库等一些基本问题，可是对于和客户的具体情况密切相关的一些问题却很少系统的考虑。甚至还存在一种误区，认为架构设计无非就是写一些空话，套话。这样子做出来架构设计，如何用于指导软件的实现呢?
IT界的技术层出不穷，面对着如此之多的技术、平台、框架、函数库，我们如何选择一组适合软件的技术?
每一个客户的软件都有自身的特点，如何才能够设计出符合客户利益的架构?
软件中往往都充斥着众多的问题，在一开始就把所有的问题都想清楚往往很难做到，但是如果不解决问题，风险又居高不下。
Solution
针对需求设计架构
架构设计就是铺设软件的主管道(例1)。我们根据什么来制定主管道的粗细、路径等因素呢?很明显，是根据城市的人口、地理位置、水源等因素来决定的。对应到软件设计也是一样的。城市的各因素就是软件中的各种需求：功能需求、非功能需求、变化案例等等。
一般来说，功能需求决定业务架构、非功能需求决定技术架构，变化案例决定架构的范围。需求方面的知识告诉我们，功能需求定义了软件能够做些什么。我们需要根据业务上的需求来设计业务架构，以使得未来的软件能够满足客户的需要。非功能需求定义了一些性能、效率上的一些约束、规则。而我们的技术架构要能够满足这些约束和规则。变化案例是对未来可能发生的变化的一个估计，结合功能需求和非功能需求，我们就可以确定一个需求的范围，进而确定一个架构的范围。
从例2中，我们看到自已字处理软件的几种需求的范例。真正的字处理软件要复杂的多。而我们最主要的就是必须认识到，架构是来自于需求的。有什么样的需求就有什么样的架构。试想一下，如果我们没有对速度的要求，我们还需要考虑这方面的设计吗?我们上面提到了几种类型的需求对架构的影响，其实还有一个很重要的需求，就是环境的需求。这并不是一个很重要的需求，但是对于部署(deployment)架构设计来说就特别重要。毕竟，我们开发出的软件是要上"战场"的，充分的考虑部署问题是非常有必要的。
例1：城市中自来水管的架设是一项非常的复杂的工程。为了需要满足每家每户的需要，自来水管组成了一个庞大的网络。在这样一个复杂的网络中，如何完成铺设的任务呢。一般的做法是，先找出问题的根源，也就是水的源头。从水源铺设一条管道通至城市，然后根据城市的区域划分，设计出主管道，剩下的就是使用的问题了，每家每户的管道最终都是连到主管道上的。因此，虽然自来水网络庞大复杂。但是真正的主管道的非常简单的。
例2：我们打算开发一个字处理软件，功能需求可以简单概括为格式化用户输入的文字，非功能需求可能是格式化大小为1000K的一段文字的处理速度不能低于10S，变化案例可能是推出多种语言版本。那么我们在设计业务架构的时候，我们会集中于如何表示文字、图象、媒体等要素，我们该需要有另外的技术架构来处理速度问题，比如缓冲技术，对于变化案例，我们也要考虑相应的架构，比如把字体独立于程序包的设计。
从需求到架构
在需求阶段，我们可以得到一些代表需求调研成果的中间产物。比如说，CRC卡片、基本用例模型、用户素材、界面原型、界面原型流程图、非功能需求、变化案例等。我们在架构设计阶段的主要工作就是要把这些需求阶段的中间产物转换为架构设计阶段的中间产物。
图 3. 需求阶段的中间产物
其实，架构设计就是要完成两项工作，一是分析，二是设计。分析是分析需求，设计则是设计软件的大致结构。很多的方法论把分析和设计两种活动分开来，但其实这两者是很难区分的，做分析的时候会想到如何设计，而思考如何设计反过来又会影响分析的效果。可以说，他们两者之间是相互联系和不断迭代的。这种形态我们将会在后面的迭代设计模式中详细的讨论。
在敏捷方法论中，需求最好是迭代进行的，也就是说一点一点的作需求。这种做法在那些需求变化快的项目中尤其适用。由于我们采用的流程是一种迭代式的流程，这里我们将会面临着如何对待上一次迭代的中间产物的问题。如果我们每一次迭代都需要修改已存在的中间产物，那么这种维护的成本未免过大。因此，敏捷方法论的基本做法是，扔掉那些已经没有用处的中间产物。还记得在第一章的时候，我们强调说软件要比文档重要。我们生成中间产物的目的都是为了生成最终的程序，对于这些已经完成作用的模型，没有必要付出额外的维护成本。
不要断章取义的采用抛弃模型的做法。因为，抛弃模型的做法需要一个适合环境的支持。后面会针对这个话题开展大范围的讨论。这里我们简单的做一个了解：
简单化：简单的模型和简单的程序。模型和程序越复杂，就需要更多的精力来处理它们。因此，我们尽可能的简化它们，为的是更容易的处理它们。
高效的沟通渠道：通过增强沟通的效果来减少对中间产物的需要。试想一下，如果我随时能够从客户那里得到需求的细节资料，那前期的需求调研就没有必要做的太细致。
角色的交叉轮换：开发人员之间建立起交换角色的机制，这样，能够尽量的避免各子系统诸侯割据的局面。
清晰的流程：或者我们可以称之为明确的过程。过程在方法论中向来都是一个重点，敏捷方法论也不例外。开发人员能够清楚的知道，今天做什么，明天做什么。过程不是给别人看的，而是给自己用的。
工具：好用的工具能够节省大量的时间，这里的工具并不仅仅指CASE工具，还包括了版本控制工具、自动化测试工具、画图工具、文档制作和管理工具。使用工具要注意成本和效益的问题。
标准和风格：语言不通是沟通的一个很大的障碍。语言从某个角度来看属于一种标准、一种风格。因此，一个团队如果采用同样的编码标准、文档标准、注释风格、制图风格，那么这个团队的沟通效率一定非常的高。
如果上述的环境你都不具备，或是欠缺好几项，那你的文档的模型还是留着的好。
仅针对需求设计架构
仅针对需求设计架构的含义就是说不要做未来才有用的事情。有时候，我们会把架构考虑的非常复杂，主要的原因就是我们把很多未来的因素放入到现在来考虑。或者，我们在开发第一个产品的时候就视图把它做成一个完美的框架。以上的这两种思路有没有错呢?没有错，这只是如何看待投入的问题，有人希望开始的时候多投入一些，这样后续的投入就会节省下来。但在现实中，由于需求的不确定性，希望通过增加开始阶段的投入来将降低未来的投入往往是难以做到的，框架的设计也绝对不是能够一蹴而就的，此这种做法并不是一个好的做法。所以我们在后头会着重论述架构设计的简单性和迭代过程，也就是因为这个理由。
例3：信贷系统
在一个银行的信贷帐务处理系统中，我们应该如何把握最初的架构思路呢?从需求上来看，这个信贷帐务处理系统有几个特点：
它不是一个单独的系统，它需要和外部的其它系统交互，例如信贷业务系统、网上银行、数据仓库系统等。
在所有的需求中，最复杂的就是它的利息计算的需求，它要求能够支持多种的利息算法。
因此，我们的架构设计首先是从系统的全局环境开始考虑。其它系统和该系统的关系如何，应该如何设计系统间的接口。通过需求的调研，系统的接口分为4类：
和企业外部系统的接口。信贷系统需要连接到人民银行的系统。
和企业内部系统的接口。信贷系统需要能够为数据仓库系统和网上银行系统提供数据。
和平级系统的接口。信贷系统需要从平级的帐户、资金、财务系统中取数据，并向帐户、押汇系统发送数据。
具体的实现策略并不在我们的讨论范围之内，但是可以看到，架构策略的制定是以需求为基础的。我们可以把这部分的需求归纳为技术架构或平台架构。
然后是利息算法的问题，我们经过统计，目前的利息计算方式有四种，可预见到的还有两种。在一开始的阶段，我们并不需要考虑具体算法的实现，但是我们需要考虑算法的实现框架，因此我们很自然的想到Strategy模式可以胜任这一工作，把不同的利息算法封装起来。而我们的工作重点也就转到定义利息算法的接口问题。通过分析、比较多种利息算法，我们定义了一个最初始的算法接口，然后由不同的利息算法来实现算法接口。虽然，这个接口目前还不是很完整，但是它会在接下去的开发过程中慢慢的完善起来。这部分的需求属于业务架构的一部分。
考虑到系统的结构非常的复杂，因此在系统结构的处理上，我们采用了层模式做为系统的基本结构。此外，在每个层，我们还定义了几个子模块来处理特定的问题。这样，我们就可以将复杂的功能有序的组织起来。
经过上述的分析，我们对系统的架构有了一个简单的认识，但是还没有结束，一个架构应该包括系统的各个基本部分，因此，我们还要考虑票据处理、报表、帐务处理等环节，但是一开始就考虑周详，这要花费大量的时间，因此我们只是简单的定义了一个原始的架构，然后在后续的开发过程中把这个架构完善起来。
模式
模式将可以帮助我们抓住重点。设计模式在书的一开始(第二章)就讨论了一个设计一个文档编辑器的问题。为了解决设计文档编辑器引出的七个问题，一共使用了8种不同的模式。这8种模式的组合其实就是架构，因为它们解决的，都是系统中最高层的问题。
在实践中，人们发现架构也是存在模式的。比如，对于系统结构设计，我们使用层模式;对于分布式系统，我们使用代理模式;对于交互系统，我们使用MVC(模型-视图-控制器)模式。模式本来就是针对特定问题的解，因此，针对需求的特点，我们也可以采用相应的模式来设计架构。
在sun网站上提供的宠物商店的范例中，就把MVC模式的思想扩展成为架构的思想，用于提供不同的界面视图：
MVC架构图，这里提供原图的概览，查看其出处请点击这里。
我们可以了解到在图的背后隐藏着的需求：系统需要支持多种用户界面，包括为普通用户提供的HTML界面，为无线用户提供的WML界面，为管理员提供的Swing界面，以及为B2B业务设计的WebService界面。这是系统最重要的需求，因此，系统的设计者就需要确定一个稳定的架构，以解决多界面的问题。相对于多界面的问题，后端的业务处理逻辑都是一致的。比如HTML界面和WML界面的功能并没有太大的差别。把处理逻辑和界面分离开来还有额外的好处，可以在添加功能的同时，不涉及界面的改动，反之亦然。这就是我们在第二篇中提到的耦合度的问题。
MVC模式正可以适用于解决该问题。系统使用控制器来为业务逻辑选择不同的界面，这就完成了MVC架构的设计思路。在架构设计的工作中，我们手头上有模式这样一张好牌，有什么理由不去使用它呢?
抓住重点
在架构设计一开始，我们就说架构是一种抽象，那就是说，架构设计摒弃了具体的细节，仅仅抓住软件最高层的概念，也就是最上层、优先级最高、风险最大的那部分需求。
我们考虑、分析、解决一个问题，一定有一个渐进的过程。架构设计就是解决问题其中比较早期的一个阶段，我们不会在架构设计这个阶段投入过多的时间(具体的原因在下文会有讨论)，因此关键点在于我们要能够在架构设计中把握住需求的重点。比如，我们在模式一节中提到了分布式系统和交互系统，分布和交互就是这两个系统的重点。那么，如果说我们面对的是一个分布式的交互系统，那么，我们就需要把这两种特性做为重点来考虑，并以此为基础，设计架构。而我们提到的宠物商店的范例也是类似的，除了MVC的架构，还有很多的设计问题需要解决，例如用于数据库访问的数据对象，用于视图管理的前端控制器，等等(具体使用到的架构模式可以访问sun的网站)。但是这些相对于MVC模式来说，属于局部的，优先级较低的部分，可以在架构确定后再来设计。
架构设计和领域专家
一个架构要设计的好，和对需求的理解是分不开的。因此在现实中，我们发现业务领域专家凭借着他对业务领域的了解，能够帮助开发人员设计出优秀的架构来。架构是需要抽象的，它是现实社会活动的一个基本模型，而业务领域的模型仅仅凭开发人员是很难设计出来的。在ERP的发展史上，我们看到MRP发展为MRPII，在发展到闭环MRP，直到发展成为现在的ERP，主要的因素是管理思想的演化，也就是说，对业务领域的理解进步了，架构才有可能进步。
因此，敏捷型架构设计的过程中，我们也非常强调领域专家的作用。
(待续)
作者简介：
林星，辰讯软件工作室项目管理组资深项目经理，有多年项目实施经验。辰讯软件工作室致力于先进软件思想、软件技术的应用，主要的研究方向在于软件过程思想、Linux集群技术、OO技术和软件工厂模式。您可以通过电子邮件 iamlinx@21cn.com 和他联系。
文章来源于领测软件测试网 https://www.ltesting.net/
