SOA架构电子政务总体应用架构设计指南

长风开放标准平台软件联盟ChangFengOpenStandardsPlatformSoftwareAlliancePAGE -PAGE142-长风联盟SOA-AP-TF-PAGEi-长风联盟电子政务总体应用架构设计指南研究报告长风开放标准平台软件联盟二○○七年五月目录TOC\o"1-4"\h\z\u第一章引论 11.1本指南的目的 11.2本指南依据的长风联盟参考文档 11.3什么是SOA电子政务总体应用架构 11.4什么是SOA电子政务总体应用架构设计 21.5本指南的章节组织 71.6应用架构设计的主要内容 71.7应用架构分解结构与参考架构(RA) 71.8应用架构设计环境 81.9应用架构设计干系人 81.10应用架构设计指南与长风联盟其他文档的关系 9第二章应用架构设计知识领域、原则和过程组 102.1应用架构设计知识领域 102.1.1SOA设计方法学 102.1.2数据建模方法学 102.1.3面向流程设计方法学 112.1.4技术领域架构设计方法学 112.1.5通用架构设计方法学 132.1.6面向对象设计方法学 192.2服务设计原则 212.2.1显式定义边界 212.2.2自治性 232.2.3服务共享大纲和契约，但不共享类 242.2.4服务兼容性基于策略 252.2.5访问的开放性 262.2.6随时可用 272.2.7粗粒度服务接口 272.2.8服务分级 282.2.9松散耦合 282.2.10可重用的服务及服务接口设计管理 292.2.11标准化的接口 302.2.12支持各种消息模式 302.2.13精确定义服务接口 312.3应用架构设计过程组 312.3.1架构启动过程组 33概述 33业务模型合理性初步分析 34架构范围定义 35功能架构 35业务分类 352.3.2架构分析过程组 36概述 36组织模型分析 38数据模型分析 38流程模型分析 38UI分析 39外部接口分析 39关键用例分析 39关键技术点分析 40服务定义 400干系人分析 401外部接口设计过程 412服务设计过程 432.3.3架构设计过程组 43概述 43总体架构设计 45框架选择 45数据模型设计 45流程设计 45关键技术点设计 45外部接口设计 46UI设计 48服务设计过程 480质量设计 481设计视图分配 482部署视图设计 483团队开发管理设计 482.3.4架构实现过程组 49概述 49工作绩效信息收集 49架构实现 492.3.5架构测试过程组 49概述 49测试规划 50服务测试 50功能测试 50性能测试 51技术指标测试 51架构优化 512.3.6架构监控过程组 51概述 51业务模型合理性跟踪 51绩效报告 522.3.7架构收尾过程组 52概述 52管理收尾 52架构进化 52第三章应用架构分解结构 533.1总体架构 533.2基础支撑层 543.2.1全景图 543.2.2硬件/网络层设计 55主机设计 55网络规划 57存储/备份设计 57其它硬件设备 603.2.3系统软件层设计 60操作系统选型 61应用服务器选型 62数据库服务器选型 63其它系统软件选型 643.2.4支撑软件层设计 64技术架构选择 64软件框架设计 67基础构件/服务设计 67其它构件 673.2.5与架构其它层关系 673.2.6相关规范与标准 673.2.7服务运行、管理和监控环境 673.3政务资源层 683.3.1政务资源层总体架构 68传统资源层面临的问题 68架构目标 69架构总图及描述 69政务资源层应用前景和趋势 703.3.2政务信息资源 70政务信息资源的封装 71政务信息资源的接入 71政务信息资源的管理 72政务信息资源的访问 733.3.3部门业务应用资源 73应用资源的封装 74应用资源的接入 74应用资源的管理 75应用资源的统一访问 753.3.4政务目录资源 76资源元数据描述 77资源编目 79安全管理 79基于目录的资源共享体系 803.4支撑服务层 813.4.1全景图 813.4.2描述 813.4.3服务构成 82公共服务 82领域服务 893.5业务应用层 913.5.1全景图 913.5.2描述 913.5.3基于SOA业务应用层的业务应用模式 92从软基础设施的视角研究模式分类 93基于SOA的资源共享应用模式 95基于SOA的业务协同应用模式 96基于SOA的不同服务渠道的应用模式 963.5.4与其它各层的关系 97业务应用层对基础支撑层的要求 97业务应用层对展现服务层的支持 98业务应用层对安全保障体系的要求 983.6展现服务层 993.6.1全景图 993.6.2适配器 1003.6.3支撑运行环境 1003.6.4具体的展现服务 1013.6.5展现服务相关的标准体系、工具集、安全保障体系 1013.7工具集 1023.7.1全景图 1033.7.2开发和部署服务 103服务的体系架构/模型 105体系架构说明 106功能模块概述 106功能模块间关系概述 107功能详细说明 107与其他服务关系 1103.8标准规范体系 1123.8.1全景图 1123.8.2基础支撑层 1123.8.3政务资源层 1163.8.4支撑服务层 1183.8.5业务应用层 1223.8.6展现服务层 1233.8.7安全保障体系 1243.9安全保障体系 126[全景图] 126安全在整个SOA体系中的作用和位置 128安全保障体系的总体逻辑框架 129安全保障体系中采用的标准规范体系框架图 1303.9.2SOA安全实施要点及方法 131端到端SOAP消息交换的安全 131Web服务策略机制 131令牌转换和信任域 133安全对话 133跨域的互信任操作 134SOA系统的安全管理制度 135第四章应用架构设计路线图 1364.1全景图 1364.2基础SOA 1374.3网络化SOA 1384.4流程支撑的SOA 138附录A术语表 141附录B架构设计资料参考 142附录C案例描述 142第一章引论本指南的目的基本目的是识别SOA电子政务领域应用架构设计知识体系普遍公认为良好做法的那一部分。识别，指一般概括性介绍，而非详尽无遗漏的说明。普遍公认，指介绍的知识和做法在绝大多数情况下适用于绝大多数的架构设计，其价值和实用性也得到了人们的广泛认同。良好做法，指一致认为，正确应用这些技能、工具和技术能够增加范围极为广泛的各种不同架构设计成功的机会。良好做法并不是说这些知识和做法一成不变地应用于或应当应用于所有的架构设计：架构设计团队负责架构的裁剪和扩展。本指南还旨在作为该职业和实践一个共同的术语汇编，为讨论、书写和应用架构设计方面的问题提供便利。这种术语汇编是一种职业必不可少的组成部分。本指南还提供了一个参考的电子政务应用架构，并结合一个具体案例讲解如何在电子政务领域进行基于SOA的应用架构设计。本指南用来指导电子政务领域政务系统建设和政务系统之间的整合任务的架构设计。而附录B列出了架构设计资料的其他来源。本指南依据的长风联盟参考文档SOA-RA-TF制定的《SOA参考架构白皮书》SOA-AP-TF制定的《SOA电子政务总体技术架构与解决方案》什么是SOA电子政务总体应用架构长风联盟依据《国家电子政务总体框架》，遵循国家电子政务标准，参照《北京市电子政务总体技术框架》，结合长风联盟SOA电子政务解决方案的实际情况，制定出长风联盟SOA总统技术架构。目标是作为长风联盟企业实施SOA架构的电子政务系统的标准型、指导性框架，实现未来电子政务系统的互联互通、资源共享，并使联盟企业可以快速、流畅、高效地构建各类政务应用系统,保障以该架构为标准的各类政务应用通畅运行。该架构将成为未来电子政务实施的重要指导。该架构又称为“五横三纵架构”。什么是SOA电子政务总体应用架构设计SOA电子政务总体应用架构设计就是把各种知识、技能、手段和技术应用于架构活动中，以达到系统建设和系统整合的要求。架构设计必须权衡质量、时间、范围和费用等方面的要求。其中：下面介绍几个通常会在系统设计中涉及的质量属性。性能指系统提供的服务要满足一定的性能衡量标准，这些标准可能包括系统反应时间以及处理交易量的能力等。通常可以根据每个用户访问的系统响应时间来衡量系统的整体性能;也可以通过系统能够处理的交易量(每秒)来衡量系统的性能。对于架构设计师来说，无论采取哪种衡量系统性能的方法来构建系统架构，这些对于性能的考虑对系统设计开发人员来说都应该是透明的，也就是说对于系统整体架构性能的考虑应该是架构设计师的工作，而不是系统设计开发人员应该关注的事情。在较传统的基于EJB或者XML-RPC的分布式计算模型中，它们的服务提供都是通过函数调用的方式进行的，一个功能的完成往往需要通过客户端和服务器来回很多次的远程函数调用才能完成。在Intranet的环境下，这些调用给系统的响应速度和稳定性带来的影响都可以忽略不计，但如果我们在基于SOA的架构中使用了很多WebService来作为服务提供点的话，我们就需要考虑性能的影响，尤其是在Internet环境下，这些往往是决定整个系统是否能正常工作的一个关键决定因素。因此在基于SOA的系统中，推荐采用大数据量低频率访问模式，也就是以大数据量的方式一次性进行信息交换。这样做可以在一定程度上提高系统的整体性能。可升级性指当系统负荷加大时，仍能够确保所需的服务质量，而不需要更改整个系统的架构。当基于SOA的系统中负荷增大时，如果系统的响应时间仍能够在可接受的限度内，那么我们就可以认为这个系统是具有可升级性的。要想理解可升级性，我们必须首先了解系统容量或系统的承受能力，也就是一个系统在保证正常运行质量的同时，所能够处理的最大进程数量或所能支持的最大用户数量。如果系统运转时已经不能在可接受时间范围内反应，那么这个系统已经到达了它的最大可升级状态。要想升级已达到最大负载能力的系统，你必须增加新的硬件。新添加的硬件可以以垂直或水平的方式加入。垂直升级包括为现在的机器增加处理器、内存或硬盘。水平升级包括在环境中添置新的机器，从而增加系统的整体处理能力。作为一个系统架构设计师所设计出来的架构必须能够处理对硬件的垂直或者水平升级。基于SOA的系统架构可以很好地保证整体系统的可升级性，这主要是因为系统中的功能模块已经被抽象成不同的服务，所有的硬件以及底层平台的信息都被屏蔽在服务之下，因此不管是对已有系统的水平升级还是垂直升级，都不会影响到系统整体的架构。可靠性指确保各应用及其相关的所有交易的完整性和一致性的能力。当系统负荷增加时，系统必须能够持续处理需求访问，并确保系统能够象负荷未增加以前一样正确地处理各个进程。可靠性可能会在一定程度上限制系统的可升级性。如果系统负荷增加时，不能维持它的可靠性，那么实际上这个系统也并不具备可升级性。因此，一个真正可升级的系统必须是可靠的系统。在基于SOA来构建系统架构的时候，可靠性也是必须要着重考虑的问题。要在基于SOA架构的系统中保证一定的系统可靠性，就必须要首先保证分布在系统中的不同服务的可靠性。而不同服务的可靠性一般可以由其部署的应用服务器或Web服务器来保证。只有确保每一个SOA系统中的服务都具有较高的可靠性，我们才能保证系统整体的可靠性能够得以保障。可用性指确保一项服务或者资源应该总是可被访问到的。可靠性可以增加系统的整体可用性，但即使系统部件出错，有时却并不一定会影响系统的可用性。通过在环境中设置冗余组件和错误恢复机制，虽然一个单独的组件的错误会对系统的可靠性产生不良的影响，但由于系统冗余的存在，使得整个系统服务仍然可用。在基于SOA来构建系统架构的时候，对于关键性的服务需要更多地考虑其可用性需求，这可以由两个层次的技术实现来支持，第一种是利用不同服务的具体内部实现内部所基于的框架的容错或者冗余机制来实现对服务可用性的支持;第二种是通过UDDI等动态查找匹配方式来支持系统整体的高可用性。在SOA架构设计师构建企业系统架构的时候，应该综合考虑这两个方面的内容，尽量保证所构建的SOA系统架构中的关键性业务能具有较高的可用性。可扩展性指在不影响现有系统功能的基础上，为系统添加新的功能或修改现有功能的能力。当系统刚配置好的时候，你很难衡量它的可扩展性，直到第一次你必须去扩展系统已有功能的时候，你才能真正去衡量和检测整个系统的可扩展性。任何一个架构设计师在构建系统架构时，为了确保架构设计的可扩展性，都应该考虑下面几个要素:低耦合，界面(interfaces)以及封装。当架构设计师基于SOA来构建企业系统架构时，就已经隐含地解决了这几个可扩展性方面的要素。这是因为SOA架构中的不同服务之间本身就保持了一种无依赖的低耦合关系;服务本身是通过统一的接口定义(可以是WSDL)语言来描述具体的服务内容，并且很好地封装了底层的具体实现。可维护性指在不影响系统其他部分的情况下修改现有系统功能中问题或缺陷的能力。当系统刚被部署时，你很难判断一个系统是否已经具备了很好的可维护性。当创建和设计系统架构时，要想提高系统的可维护性，你必须考虑下面几个要素:低耦合、模块性以及系统文档记录。在企业系统可扩展性中我们已经提到了SOA架构能为系统中暴露出来的各个子功能模块也就是服务带来低耦合性和很好的模块性。关于系统文档纪录，除了底层子系统的相关文档外，基于SOA的系统还会引用到许多系统外部的由第三方提供的服务，因此如果人力资源准许的话，应该增加专职的文档管理员来专门负责有关整个企业系统所涉及的所有外部服务相关文档的收集、归类和整理，这些相关的文档可能涉及到第三方服务的接口(可以是WSDL)、服务的质量和级别、具体性能测试结果等各种相关文档。基于这些文档，就可以为SOA架构设计师构建企业SOA架构提供很好的文档参考和支持。可管理性指管理系统以确保整个系统的可升级性、可靠性、可用性、性能和安全性的能力。具有可管理性的系统，应具备对服务质量需求(QoS)的系统监控能力，通过改变系统的配置从而可以动态地改善服务质量，而不用改变整体系统架构。一个好的系统架构必须能够监控整个系统的运行情况并具备动态系统配置管理的功能。在对复杂系统进行系统架构建模时，SOA架构设计师应该尽量考虑利用将系统整体架构构建在已有的成熟的底层系统框架(Framework)上。安全性指确保系统安全不会被危及的能力。目前，安全性应该说是最困难的系统质量控制点。这是因为安全性不仅要求确保系统的保密和完整性，而且还要防止影响可用性的服务拒绝(Denial-of-Service)攻击。这就要求当SOA架构设计师在构建一个架构时，应该把整体系统架构尽可能地分割成各个子功能模块，在将一些子功能模块暴露为外部用户可见的服务的时候，要围绕各个子模块构建各自的安全区，这样更便于保证整体系统架构的安全。如果一个子模块受到了安全攻击，也可以保证其他模块相对安全。如果企业SOA架构中的一些服务是由WebService实现的，在考虑这些服务安全性的时候也要同时考虑效率的问题，因为WS-Security会为WebService带来一定的执行效率损耗。高质量的架构设计还考虑了技术风险应对的因素。应对变化，权衡不变与变化是架构设计永恒的主题。架构设计中还必须考虑SOA的独特性,例如：服务分类方法等。[1]按服务在系统建设中的用途划分：[2]按服务的功能划分：基本服务：数据中心的服务和逻辑中心的服务中介服务：技术网关、适配器、外观、装饰服务以流程为中心的服务公共企业服务：为跨企业集成提供接口，例如SMS、Email等另外应用程序前端是SOA的激活元素。本指南的章节组织主要分4章介绍。第1章引论第2章应用架构设计知识领域、设计原则和过程组第3章应用架构分解结构第4章应用架构设计路线图应用架构设计的主要内容依据SOA-RA-TF的参考架构，解决电子政务应用领域如何产出一个SOA应用架构的问题：架构的生命期构成整体架构设计过程组架构分解结构(五横三纵架构)知识领域:服务参考模型架构侧面系(生命周期模型和4+1视图)应用架构分解结构与参考架构(RA)应用架构分解结构中的基础支撑层中的系统软件尽量按照RA标准实现，如不能满足，架构上应考虑松耦合的互连互通，保障符合RA标准的服务库和应用系统能够和本应用架构协同。另外RA为应用架构分解结构中的服务开发运行体系提供支撑机制，如ESB等。应用架构设计环境本指南假定架构设计在项目环境下进行。应用架构设计受到一定环境因素的影响和约束，并反过来对这些因素产生影响：应用领域标准规范组织过程资产公司战略要求技术环境项目要求管理因素架构设计和项目管理和组织日常运作管理是密切相关的，但本指南不涉及相关内容，请参考相关书籍和文献资料。应用架构设计干系人架构设计要考虑架构设计干系人的要求。高层管理人员项目发起人项目经理架构设计师需求人员开发人员测试人员客户应用架构设计指南与长风联盟其他文档的关系应用架构设计知识领域、原则和过程组应用架构设计知识领域SOA设计方法学SOA设计方法并非全新的方法论，而是继承了传统的面向对象的设计方法以及面向过程的设计方法，同时又增加了SCA,，SDO，BPEL等技术，融入了面向服务的设计方法，服务参考模型OASISRM里的内容映射，具体内容包括服务定义、服务设计、服务管理、服务开发、服务测试和服务部署。数据建模方法学传统的数据建模方法学是面向一个应用系统内部的实体的建模方法学，而在当前数据整合、应用整合的需求下，数据建模还要考虑在不同系统间进行数据交换和数据共享的需求。基于业务效率的考虑，从业务流程出发的思路改变了数据模型。只有你从业务流程的角度来看待数据的时候，数据模型才能算真正完成。面向流程设计方法学阐述了一种以实现流程优化的流程系统设计思想。这种设计思想是面向业务流程的，不同于传统MIS系统面向部门职能的设计思想。首先把系统设计区分为原理层设计和技术层设计两个层次，然后从业务流程设计、数据模型设计和技术架构设计三个方面论述了原理层设计的基本思想。技术领域架构设计方法学大型IT系统的设计通常遵循七层架构的设计方法，包括：界面层该层是直接面向用户（包括公众、企业、业务人员、行政管理人员、领导等使用者）的统一的系统界面。界面层利用业界主流的IT技术支持多种渠道接入和交互（如互联网、电话、手机短信等接入方式），以及统一的身份认证及权限管理。应用层应用层提供所有的信息应用和系统管理的业务逻辑，分解业务请求，通过应用支撑层进行数据处理，并将返回信息组织成所需的格式提供给客户端。应用系统分为四大部分：面向公众和企业的外网应用——审批门户（网上审批系统前台），提供网上申报和反馈查询等在线服务功能；面向公务员的审批服务平台，实现业务审批、监督检察、业务调度、决策支持等功能；面向公务员的政府资源共享平台（数据共享与交换平台），实现基于审批业务的数据交换与基于委办局现有信息资源的数据共享使用等功能。面向公务员的开放办公平台，实现基于开放的桌面办公系统，实现对审批过程数据的保存及归档等。应用支撑层应用支撑层构建在J2EE应用服务器之上，提供了一个应用基础平台DC-BPIP，并提供大量公共服务和业务构件，提供构件的运行、开发和管理环境，最大限度提高开发效率，降低工程实施、维护的成本和风险。应用支撑层采用了行业应用的先进体系结构，以建立高性能、高可靠性、高扩展性的应用系统，满足客户快速发展的业务需求。信息资源层信息资源层是整个系统的信息资源中心，涵盖全市所有与行政审批相关的结构化和非结构化数据。它是企业信息资源的存储和积累，为系统应用提供数据访问服务、备份、存储功能。IT基础平台层IT基础平台为系统的软硬件以及网络基础平台，分为三个部分：系统软件、硬件支撑平台、和网络支撑平台。其中，系统软件包括中间件、数据库服务器软件等；硬件支撑平台包括：主机、存储、备份等硬件设备；网络支撑为系统运行所依赖的网络环境。它对上层应用起到技术支撑作用支撑体系层系统建设和推广运行仅仅依赖应用系统建设、硬件网络建设是不够的，需要在系统安全方面、标准化方面、以及系统运维三个不同层面的工作来共同支撑。只有这样，才能使系统建设顺利进行，也才能保证系统能顺利推广、稳定运行。法律法规层以上各个层面的建设，需要依托于现有的法律、法规及一些规范才可成功运行。系统的分析、设计、实施都必须充分考虑这些因素。只有切实符合这些规范，系统才能与建设单位共同发展，得到各级用户的认可。而利用RUP的设计思想，则将架构设计概括为4+1视图：逻辑视图。逻辑视图关注功能，不仅包括用户可见的功能，还包括为实现用户功能而必须提供的"辅助功能模块"；它们可能是逻辑层、功能模块等。开发视图。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。处理视图。处理视图关注进程、线程、对象等运行时概念，以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题。物理视图。物理视图关注"目标程序及其依赖的运行库和系统软件"最终如何安装或部署到物理机器，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。场景视图。关注业务的应用场景。通用架构设计方法学架构设计是一种权衡（trade-off）。一个问题总是有多种的解决方案。而我们要确定唯一的架构设计的解决方案，就意味着我们要在不同的矛盾体之间做出一个权衡。我们在设计的过程总是可以看到很多的矛盾体：开放和整合，一致性和特殊化，稳定性和延展性等等。任何一对矛盾体都源于我们对软件的不同期望。可是，要满足我们希望软件稳定运行的要求，就必然会影响我们对软件易于扩展的期望。我们希望软件简单明了，却增加了我们设计的复杂度。没有一个软件能够满足所有的要求，因为这些要求之间带有天生的互斥性。而我们评价架构设计的好坏的依据，就只能是根据不同要求的轻重缓急，在其间做出权衡的合理性。目标我们希望一个好的架构能够：重用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。重用是我们不断追求的目标之一，但事实上，做到这一点可没有那么容易。在现实中，人们已经在架构重用上做了很多的工作，工作的成果称为框架（Framework），比如说Windows的窗口机制、J2EE平台等。但是在企业商业建模方面，有效的框架还非常的少。透明：有些时候，我们为了提高效率，把实现的细节隐藏起来，仅把客户需求的接口呈现给客户。这样，具体的实现对客户来说就是透明的。一个具体的例子是我们使用JSP的tag技术来代替JSP的嵌入代码，因为我们的HTML界面人员更熟悉tag的方式。延展：我们对延展的渴求源于需求的易变。因此我们需要架构具有一定的延展性，以适应未来可能的变化。可是，如上所说，延展性和稳定性，延展性和简单性都是矛盾的。因此我们需要权衡我们的投入/产出比。以设计出具有适当和延展性的架构。简明：一个复杂的架构不论是测试还是维护都是困难的。我们希望架构能够在满足目的的情况下尽可能的简单明了。但是简单明了的含义究竟是什么好像并没有一个明确的定义。使用模式能够使设计变得简单，但这是建立在我熟悉设计模式的基础上。对于一个并不懂设计模式的人，他会认为这个架构很复杂。对于这种情况，我只能对他说，去看看设计模式。高效：不论是什么系统，我们都希望架构是高效的。这一点对于一些特定的系统来说尤其重要。例如实时系统、高访问量的网站。这些值的是技术上的高效，有时候我们指的高效是效益上的高效。例如，一个只有几十到一百访问量的信息系统，是不是有必要使用EJB技术，这就需要我们综合的评估效益了。安全：安全并不是我们文章讨论的重点，却是架构的一个很重要的方面。规则为了达到上述的目的，我们通常需要对架构设计制定一些简单的规则：功能分解顾名思义，就是把功能分解开来。为什么呢？我们之所以很难达到重用目标就是因为我们编写的程序经常处于一种好像是重复的功能，但又有轻微差别的状态中。我们很多时候就会经不住诱惑，用拷贝粘贴再做少量修改的方式完成一个功能。这种行为在XP中是坚决不被允许的。XP提倡"Onceandonlyonce"，目的就是为了杜绝这种拷贝修改的现象。为了做到这一点，我们通常要把功能分解到细粒度。很多的设计思想都提倡小类，为的就是这个目的。所以，我们的程序中的类和方法的数目就会大大增长，而每个类和方法的平均代码却会大大的下降。可是，我们怎么知道这个度应该要如何把握呢，关于这个疑问，并没有明确的答案，要看个人的功力和具体的要求，但是一般来说，我们可以用一个简单的动词短语来命名类或方法的，那就会是比较好的分类方法。我们使用功能分解的规则，有助于提高重用性，因为我们每个类和方法的精度都提高了。这是符合大自然的原则的，我们研究自然的主要的一个方向就是将物质分解。我们的思路同样可以应用在软件开发上。除了重用性，功能分解还能实现透明的目标，因为我们使用了功能分解的规则之后，每个类都有自己的单独功能，这样，我们对一个类的研究就可以集中在这个类本身，而不用牵涉到过多的类。根据实际情况决定不同类间的耦合度虽然我们总是希望类间的耦合度比较低，但是我们必须客观的评价耦合度。系统之间不可能总是松耦合的，那样肯定什么也做不了。而我们决定耦合的程度的依据何在呢？简单的说，就是根据需求的稳定性，来决定耦合的程度。对于稳定性高的需求，不容易发生变化的需求，我们完全可以把各类设计成紧耦合的（我们虽然讨论类之间的耦合度，但其实功能块、模块、包之间的耦合度也是一样的），因为这样可以提高效率，而且我们还可以使用一些更好的技术来提高效率或简化代码，例如Java中的内部类技术。可是，如果需求极有可能变化，我们就需要充分的考虑类之间的耦合问题，我们可以想出各种各样的办法来降低耦合程度，但是归纳起来，不外乎增加抽象的层次来隔离不同的类，这个抽象层次可以是具体的类，也可以是接口，或是一组的类（例如Beans）。我们可以借用Java中的一句话来概括降低耦合度的思想："针对接口编程，而不是针对实现编程。设计不同的耦合度有利于实现透明和延展。对于类的客户（调用者）来说，他不需要知道过多的细节（实现），他只关心他感兴趣的（接口）。这样，目标类对客户来说就是一个黑盒子。如果接口是稳定的，那么，实现再怎么扩展，对客户来说也不会有很大的影响。以前那种牵一发而动全身的问题完全可以缓解甚至避免。其实，我们仔细的观察GOF的23种设计模式，没有一种模式的思路不是从增加抽象层次入手来解决问题的。同样，我们去观察Java源码的时候，我们也可以发现，Java源码中存在着大量的抽象层次，初看之下，它们什么都不干，但是它们对系统的设计起着重大的作用。够用就好我们在上一章中就谈过敏捷方法很看重刚好够用的问题，现在我们结合架构设计来看：在同样都能够满足需要的情况下，一项复杂的设计和一项简单的设计，哪一个更好。从敏捷的观点来看，一定是后者。因为目前的需求只有10项，而你的设计能够满足100项的需求，只能说这是种浪费。你在设计时完全没有考虑成本问题，不考虑成本问题，你就是对开发组织的不负责，对客户的不负责。应用模式这篇文章的写作思路很多来源于对模式的研究。因此，文章中到处都可以看到模式思想的影子。模式是一种整理、传播思想的非常优秀的途径，我们可以通过模式的方式学习他人的经验。一个好的模式代表了某个问题研究的成果，因此我们把模式应用在架构设计上，能够大大增强架构的稳定性。抽象架构的本质在于其抽象性。它包括两个方面的抽象：业务抽象和技术抽象。架构是现实世界的一个模型，所以我们首先需要对现实世界有一个很深的了解，然后我们还要能够熟练的应用技术来实现现实世界到模型的映射。因此，我们在对业务或技术理解不够深入的情况下，就很难设计出好的架构。当然，这时候我们发现一个问题：怎样才能算是理解足够深入呢。我认为这没有一个绝对的准则。一次，一位朋友问我：他现在做的系统有很大的变化，原先设计的工作流架构不能满足现在的要求。他很希望能够设计出足够好的工作流架构，以适应不同的变化。但是他发现这样做无异于重新开发一个lotusnotes。我听了他的疑问之后觉得有两点问题：首先，他的开发团队中并没有工作流领域的专家。他的客户虽然了解自己的工作流程，但是缺乏足够的理论知识把工作流提到抽象的地步。显然，他本身虽然有技术方面的才能，但就工作流业务本身，他也没有足够的经验。所以，设计出象notes那样的系统的前提条件并不存在。其次，开发一个工作流系统的目的是什么。原先的工作流系统运作的不好，其原因是有变化发生。因此才有改进工作流系统的动机出现。可是，毕竟notes是为了满足世界上所有的工作流系统而开发的，他目前的应用肯定达不到这个层次。因此，虽然做不到最优的业务抽象，但是我们完全可以在特定目的下，特定范围内做到最优的业务抽象。比如说，我们工作流可能的变化是工组流路径的变化。我们就完全可以把工作流的路径做一个抽象，设计一个可以动态改变路径的工作流架构。有些时候，我们虽然在技术上和业务上都有所欠缺，没有办法设计出好的架构。但是我们完全可以借鉴他人的经验，看看类似的问题别人是如何解决的。这就是我们前面提到的模式。我们不要把模式看成是一个硬性的解决方法，它只是一种解决问题的思路。MartinFowler曾说：“模式和业务组件的区别就在于模式会引发你的思考。”在《分析模式》一书中，MartinFowler提到了分析和设计的区别。分析并不仅仅只是用用例列出所有的需求，分析还应该深入到表面需求的的背后，以得到关于问题本质的MentalModel。然后，他引出了概念模型的概念。概念模型就类似于我们在讨论的抽象。MartinFowler提到了一个有趣的例子，如果要开发一套软件来模拟桌球游戏，那么，用用例来描述各种的需求，可能会导致大量的运动轨迹的出现。如果你没有了解表面现象之后隐藏的运动定律的本质，你可能永远无法开发出这样一个系统。关于架构和抽象的问题，在后面的文章中有一个测量模式的案例可以很形象的说明这个问题。架构的一些误解我们花了一些篇幅来介绍架构的一些知识。现在回到我们的另一个主题上来。对于一个敏捷开发过程，架构意味着什么，我们该如何面对架构。这里我们首先要澄清一些误解：误解1：架构设计需要很强的技术能力。从某种程度来说，这句话并没有很大的错误。毕竟，你的能力越强，设计出优秀架构的几率也会上升。但是能力和架构设计之间并没有一个很强的联系。即使是普通的编程人员，他一样有能力设计出能实现目标的架构。误解2：架构由专门的设计师来设计，设计出的蓝图交由程序员来实现。我们之所以会认为架构是设计师的工作，是因为我们喜欢把软件开发和建筑工程做类比。但是，这两者实际上是有着很大的区别的。关键之处在于，建筑设计已经有很长的历史，已经发展出完善的理论，可以通过某些理论（如力学原理）来验证设计蓝图。可是，对软件开发而言，验证架构设计的正确性，只能够通过写代码来验证。因此，很多看似完美的架构，往往在实现时会出现问题。误解3：在一开始就要设计出完善的架构。这种方式是最传统的前期设计方式。这也是为XP所摒弃的一种设计方式。主要的原因是，在一开始设计出完美的架构根本就是在自欺欺人。因为这样做的基本假设就是需求的不变性。但需求是没有不变的（关于需求的细节讨论，请参看拙作『需求的实践』）。这样做的坏处是，我们一开始就限制了整个的软件的形状。而到实现时，我们虽然发现原来的设计有失误之处，但却不愿意面对现实。这使得软件畸形的生长。原本一些简单的问题，却因为别扭的架构，变得非常的复杂。这种例子我们经常可以看到，例如为兼容前个版本而导致的软件复杂性。而2000年问题，TCP/IP网络的安全性问题也从一个侧面反映了这个问题的严重性。误解4：架构蓝图交给程序员之后，架构设计师的任务就完成了。和误解2一样，我们借鉴了建筑工程的经验。我们看到建筑设计师把设计好的蓝图交给施工人员，施工人员就会按照图纸建造出和图纸一模一样的大厦。于是，我们也企图在软件开发中使用这种模式。这是非常要命的。软件开发中缺乏一种通用的语言，能够充分的消除设计师和程序员的沟通隔阂。有人说，UML不可以吗？UML的设计理念是好的，可以减轻沟通障碍问题。可是要想完全解决这个问题，UML还做不到。首先，程序员都具有个性化的思维，他会以自己的思维方式去理解设计，因为从设计到实现并不是一项机械的劳动，还是属于一项知识性的劳动（这和施工人员的工作是不同的）。此外，对于程序员来说，他还极有可能按照自己的想法对设计图进行一定的修改，这是非常正常的一项举动。更糟的是，程序员往往都比较自负，他们会潜意识的排斥那些未经过自己认同的设计。架构设计的过程模式通常我们认为模式都是用在软件开发、架构设计上的。其实，这只是模式的一个方面。模式的定义告诉我们，模式描述了一个特定环境的解决方法，这个特定环境往往重复出现，制定出一个较好的解决方法有利于我们在未来能有效的解决类似的问题。其实，在管理学上，也存在这种类似的这种思维。称为结构性问题的程序化解决方法。所以呢，我们完全可以把模式的思想用在其它的方面，而目前最佳的运用就是过程模式和组织模式。在我们的文章中，我们仅限于讨论过程模式。我们讨论的过程仅限于面向对象的软件开发过程。我们称之为OOSP（object-orientedsoftwareprocess）。因为我们的过程需要面向对象特性的支持。当然，我们的很多做法一样可以用在非OO的开发过程中，但是为了达到最佳的效果，我建议您使用OO技术。面向对象设计方法学面向对象方法(Object-OrientedMethod)是一种把面向对象的思想应用于软件开发过程中，指导开发活动的系统方法，简称OO(Object-Oriented)方法，是建立在“对象”概念基础上的方法学。对象是由数据和容许的操作组成的封装体，与客观实体有直接对应关系，一个对象类定义了具有相似性质的一组对象。而每继承性是对具有层次关系的类的属性和操作进行共享的一种方式。所谓面向对象就是基于对象概念，以对象为中心，以类和继承为构造机制，来认识、理解、刻画客观世界和设计、构建相应的软件系统。面向对象方法作为一种新型的独具优越性的新方法正引起全世界越来越广泛的关注和高度的重视，它被誉为"研究高技术的好方法"，更是当前计算机界关心的重点。十多年来，在对OO方法如火如荼的研究热潮中，许多专家和学者预言：正像70年代结构化方法对计算机技术应用所产生的巨大影响和促进那样，90年代OO方法会强烈地影响、推动和促进一系列高技术的发展和多学科的综合。用计算机解决问题需要用程序设计语言对问题求解加以描述（即编程），实质上，软件是问题求解的一种表述形式。显然，假如软件能直接表现人求解问题的思维路径（即求解问题的方法），那么软件不仅容易被人理解，而且易于维护和修改，从而会保证软件的可靠性和可维护性，并能提高公共问题域中的软件模块和模块重用的可靠性。面向对象的机能念和机制恰好可以使得按照人们通常的思维方式来建立问题域的模型，设计出尽可能自然地表现求解方法的软件。面向对象的基本概念：对象：对象是要研究的任何事物。从一本书到一家图书馆，单的整数到整数列庞大的数据库、极其复杂的自动化工厂、航天飞机都可看作对象，它不仅能表示有形的实体，也能表示无形的（抽象的）规则、计划或事件。对象由数据（描述事物的属性）和作用于数据的操作（体现事物的行为）构成一独立整体。从程序设计者来看，对象是一个程序模块，从用户来看，对象为他们提供所希望的行为。在对内的操作通常称为方法。类：类是对象的模板。即类是对一组有相同数据和相同操作的对象的定义，一个类所包含的方法和数据描述一组对象的共同属性和行为。类是在对象之上的抽象，对象则是类的具体化，是类的实例。类可有其子类，也可有其它类，形成类层次结构。消息：消息是对象之间进行通信的一种规格说明。一般它由三部分组成：接收消息的对象、消息名及实际变元。面向对象主要特征：封装性：封装是一种信息隐蔽技术，它体现于类的说明，是对象的重要特性。封装使数据和加工该数据的方法（函数）封装为一个整体，以实现独立性很强的模块，使得用户只能见到对象的外特性（对象能接受哪些消息，具有那些处理能力），而对象的内特性（保存内部状态的私有数据和实现加工能力的算法）对用户是隐蔽的。封装的目的在于把对象的设计者和对象者的使用分开，使用者不必知晓行为实现的细节，只须用设计者提供的消息来访问该对象。继承性：继承性是子类自动共享父类之间数据和方法的机制。它由类的派生功能体现。一个类直接继职其它类的全部描述，同时可修改和扩充。继职具有传达室递性。继职分为单继承（一个子类只有一父类）和多重继承（一个类有多个父类）。类的对象是各自封闭的，如果没继承性机制，则类对象中数据、方法就会出现大量重复。继承不仅支持系统的可重用性，而且还促进系统的可扩充性。多态性：对象根据所接收的消息而做出动作。同一消息为不同的对象接受时可产生完全不同的行动，这种现象称为多态性。利用多态性用户可发送一个通用的信息，而将所有的实现细节都留给接受消息的对象自行决定，如是，同一消息即可调用不同的方法。例如：Print消息被发送给一图或表时调用的打印方法与将同样的Print消息发送给一正文文件而调用的打印方法会完全不同。多态性的实现受到继承性的支持，利用类继承的层次关系，把具有通用功能的协议存放在类层次中尽可能高的地方，而将实现这一功能的不同方法置于较低层次，这样，在这些低层次上生成的对象就能给通用消息以不同的响应。在OOPL中可通过在派生类中重定义基类函数（定义为重载函数或虚函数）来实现多态性。综上可知，在OO方法中，对象和传递消息分别表现事物及事物间相互联系的概念。类和继承是是适应人们一般思维方式的描述范式。方法是允许作用于该类对象上的各种操作。这种对象、类、消息和方法的程序设计范式的基本点在于对象的封装性和类的继承性。通过封