关于什么是架构，已经有很多文章在讨论了，本文不予以探讨。
关于架构的类型，业界的定义也各不相同，《架构的类型》对这个问题进行了探讨，可供参考。
此处所探讨的架构可能包含了企业架构、系统架构、软件架构、信息架构、SOA架构等方面的部分要素，所适用的行业，也仅限于互联网行业。在此，引出了构建良好架构的第一个基本原则：依据业务特征选择架构。例如，Amazon、EBay、FaceBook、YouTube等互联网企业的架构都非常的不同，每家公司都有自己独特的架构特征，首要因素就在于第一要素。

之所以称之为哲学原则，首先它们比较虚，就像黑洞那么虚；其次度量起来比较困难，没有一个统一的标准，也很难定义标准，例如不同机构对客户满意的定义就不一样；再次它们的确很通用，在架构的各个阶段、各个层面、各种粒度都适用。
它包含如下子元素：

• 使客户(所有直接或间接使用这个系统的人都是客户)满意 – 功能、质量、使用、体验
• 良好的投资回报率 — 复用、免费产品、成型产品
• 足够敏捷，适应业务的发展，且能够快速推出新业务 – 可发展性
• 支撑企业核心竞争力
• 简单又实用
• 强壮又稳定 （ 架构设计必须考虑到故障—业务故障的可恢复性、技术故障的可恢复性，非常状态的故障：电力不足、机房断网、自然灾害等，冗余和错误恢复也是达到稳定的必要手段）
• 术语一致性（有点像统一思想、统一口径）
• 可维护性
• 支持未来的发展
• 对运营友好 （尽可能自动化，是对运营不错的支持）

“量变是指事物单 纯数量上的增加或减少，事物保持其质的稳定性。质变是指事物根本性质的变化，在这阶段，事物处于剧烈的变化之中，其平衡静止被打破，旧的事物转化为新事 物。事物的变化总是先从量变开始的，待量变积累到一定程度后，才会发生质变，其中量变是质变的必然前提，质变是量变的必然结果，量变→质变→新的量变是事 物发展的基本规律”。这条哲学规律同样适用与系统架构，每次大的系统架构的变化，背后的动因都是”量”引起的【类似window这样的系统架构变化的动因，不在此处的探讨】。在互联网领域，如下主体的量起到很大的作用：
基本量：

• 用户 — 总量/日访问量/并发量/增长率
• 访问量（PV） — 日访问量/并发量/响应周期
• 产品 — 数量/业务领域量

被动量：

• 业务数据 — 历史总量/日变化量/并发量/增长率
• 系统日志 — 一段区间总量/日生成量
• 业务日志 — 历史总量/日变化量/并发量
• 事务量 — 日变化量/并发量/响应周期
• 外部网络 — 流量/并发量
• 内部网络 —并发量
• 网络连接 —并发量
• 图片 —总量/日访问量/并发量/增长率
• 项目【包括日常升级、日常BUG维护】 — 平均开发周期/项目组成员增长率/测试周期/发布时间
• BUG — 确定原因周期/响应周期
• 系统服务（SOA角度的服务） — 总量
• 设备 — 总量
• 内部抱怨 — 声贝的大小
• 停机维护 — 次数/时间

基本量是基础，它驱动被动量的变化，例如用户，日访问量会引起业务数据、网络连接等的变化，基本量的变化对架构的影响最大，时刻关注基本量的升降。
【注意：】不用业务领域，重点关注的主体略有差别

上面是针对互联网产品的一种架构【产品架构和业务架构是都需要针对自身的特点进行划分，不具有通用性】。

• 产品架构的目的

能够描绘当前产品的关系、分类；

能够体现公司的核心价值、核心竞争力；

能够实现公司的战略意图；

能够支撑现有产品的管理和标准化进程、以及未来产品的规划；

能够指导产品的可持续发展、创新；

为技术架构提供产品输入。

• 业务架构的目的

能够描绘当前业务的关系；

能够支撑公司的战略；

能够支撑产品在既定方向上发展；

能够支撑业务的发展和敏捷；

为技术架构提供业务输入。

• 技术架构的目的

能够描述当前的IT状况；

能够支撑对产品的发展；

能够为客户提供高质量的服务【非功能性方面的需求】。

为技术架构选择的几个子架构域：

1. 信息域

   此处的信息特指用户交互层面的信息、跨系统的信息、内部管理的信息。本域内关注用户信息展示、信息聚合、信息共享、信息交换、信息分析和挖掘等。

2. 基础技术域

   支撑IT的基础设施，该域包含硬件基础、系统基础、应用基础环境、通用技术（例如：工作流、ESB、搜索等）、程序驻留环境（类似FaceBook的开放平台）等。

3. 数据域

   支撑数据的存储（数据库存储、文件存储【例如：BigTable】、甚至存储在S3中）、访问（透明统一的访问）、分布（物理分布、水平切分数据、垂直切分数据）、缓存、备份、归档等。

4. 部署域

   支撑系统（此处单指一个独立的物理整体，例如运行在一个JVM上的所有的内容）和服务（单指SOA服务）的运行、管理、发布、分布（同城、异地）、日志等。

5. 治理域

   为公司业务的运营提供不同粒度的（硬件、系统粒度、产品粒度、服务粒度、客户粒度等）监控、报警、控制、隔离，以及服务的版本管理等。

6. 安全域

   为公司业务的安全提供硬件、软件、业务等方面的支撑。

7. 测试域

   为产品提供测试环境、生产环境、沙箱环境、性能环境等的支撑。

8. 分析域

   支撑公司运营、管理、客户分析、智能系统等（从简单的URL分析、到服务路径的分析、定向客户分析等）。

架构的三要素（产品、业务、技术）以战略为核心，战略影响三要素的发展；业务支撑战略、产品实现战略、技术实施战略。

架构的三要素之间互相支撑、互相制衡。

从低级生物到高级生物、从小企业到大企业都遵循了进化的原则，大凡违背这些原则的事物都会消失、失败。架构也是如此，从简单到复杂，逐步进化，逐步发展，每经历一个痛苦阶段，都会带来质的飞跃，都能够再次适应当前的环境，从而获得生存和发展。

1）、决定系统不做成什么样子， 与决定将它做成什么样子同样重要
不去满足所有的需要， 而是让系统具备可扩展性， 使其能够向上兼容。
2）、有进有退
在架构进化的过程中，是所有要素都同步进化吗？我们看看生物的进化过程，在不同的时期有些部件会进化，有些部件会保持不变，甚至有些部件会退化，这是自然选择的结果。架构也是如此，商业环境的变化，公司战略的变化，必然要求我们作出选择 — 可能加强、可能弱化、可能维持现状。
3）、进化的要素
对于产品架构、业务架构的变化主要依赖第一要素、战略、业务指标、营收指标等商业方面的输入。
技术架构层面，具体那些要素应该变化、变多少、如何变，依赖产品和业务架构、第二要素、第三要素的组合输入或者单个输入。例如，第二要素的强壮性，要达到这一目标，可以选择增强测试、增强基础技术架构、增强信息域、加强治理等要素来实现。具体选择哪一个域中的那些要素来开展？这就需要架构依据环境做出适当的选择。
4）、控制节奏
一个好的架构进化过程，就象一曲优美的乐章、一台完美的多幕剧，让所有受众都赏心悦目，赞叹不已。

案例：Amazon 、FaceBook、EBay等，从创立之初到今天，每一家公司的架构都发生了翻天覆地的变化。

架构的规划，指在当前情况下，为一段期间内明确路线图，确保我们的进化是有序的，可控的，清晰的；以及容量的规划（系统不是无限可伸缩的，到了一定量级，必然要提前进行质变）。

架构的预测，指在量能不断变化的过程中，提前预估架构可能存在的风险，从而提前实施调整和相关的准备工作。例如：提前研究新产品、提前研究新技术等。

备注：
A：新增表等类型的操作，不属于数据域变化的范畴【此处探讨的更多是架构一个层面的问题，例如：涉及到数据的分表，那么就属于架构范畴】。
B：用户数量变化时，对于做产品独立销售、SAAS软件等等类型的公司，其作用效果与本文所指有所不同。
C：忽略的意思是不要为其考虑专门的架构，而不是不进行对应域的相关工作。例如测试域，可以不做测试架构方面的工作，但测试却是必须的，即使只有一个人使用的软件，也要考虑测试，部署等方面的问题。
D：描述某一要素的词语”忽略”、”简单”、”仔细”、”专业”等，只表明了一种重视程度，而不是必须达到某一级别。毕竟进化时的选择，是所有外部因素集体作用的结果，而非单一因素必然促使某些要素必然发生变化。

1. 鼓励异步

   不仅仅是技术的业务，业务也要考虑异步

2. 虚拟化组件

   减少物理依赖，增强部署灵活性

3. 数据切分

   按照某种原则分布存储数据；读写分流

4. Cache

   缓存一切值得缓存的，不得不缓存的内容

5. 避免cluster方案

   带来的麻烦比好处还多

6. SOA思想

   它是一个宝库，在架构的每个层面，都有丰富的研究成果，可供我们汲取

7. 无状态

   把状态都放在存储中，避免带状态的服务

8. 定制部分关键技术架构组件

   通过购买商业软件、使用开源软件可以极大的降低成本，同时加速技术架构的成型，不利之处是：这些通用软件总会存在不适应症、以及不能完全满足我们的非功能性指标。通过对各大网站的架构进行分析，可以发现，对于某些关键技术架构组件的定制，是解决问题的最好方式

9. 技术架构标准化、简单化

   技术架构尽可能标准化，避免不断引进新技术，一切以简单为原则，切忌为了技术而复杂化架构。例如，不是每家公司都必须构建和Google一样的基础技术平台，简单的技术平台一样能够为客户提供高质量的服务；架构的变化一定要遵循量变引起质变的原则，为2年的量而改造当前系统失败的几率会很高。

从理论到实践上，都积累了丰富的经验，下一阶段，我们将会在深入业务SOA的同时，不断完善和发展我们的SOA技术平台。

在采用SOA思想的过程中，我们从下面2个方面入手：

首先，从业务层面入手，用SOA思想梳理业务架构。化解业务敏捷的要求，同时支撑支付宝的开放战略。在此之前，我们在进行业务架构分析的时候，更多的是关注业务的合理性，可行性等，在业务发展的初期，这种做法能够满足我们快速开发系统，及时占领市场的需要。在05年中，我们预见到现有的业务架构，将不能支撑我们公司快速发展的需要，例如：我们的注册会员飞速奔向1亿。此时，我们就开始探讨和规划SOA思想。因此在06年，我们果断的引入SOA思想，用SOA的思想不断重构我们的业务架构。在这个过程中，随着数次公司战略的调整，业务架构都能够灵活应对，达到了业务敏捷化的目的 — 这也是SOA思想的核心。
业务架构的SOA化，是我们开展技术SOA的一个充要条件，没有这一步，我们将会非常艰难，甚至无从下手。
接着，技术层面的SOA，构建一个适合支付宝的SOA技术平台，来支撑业务SOA化的需要。针对支付宝的业务特点和要求，我们优先考虑实现如下SOA要素：

A：以服务为基本单元。技术平台提供与之对应的组件编程模型，业务层面的每一个服务，都能够方便的封装位技术层面额一个组件，例如：客户系统中的注册、登录等，都对应一个组件，每个组件都是独立的，在部署的时候，我们可以灵活选择和组合,可以依据SLA的要求，做出多种部署策略。

B：基于统一标准。在此，我们选择了ESB产品提供支撑，对外提供SOAP、REST、Hessian等标准的支持；对内统一采用定制的标准。

C：分布的能力。所有的服务都能够透明的分布，为外部消费者使用。

D：鼓励扩展。技术平台提供扩展的能力，例如：客户注册后的业务扩展点，业务部门要求依据客户注册来源、客户所在省、客户年龄等，进行不同的业务处理，而且这些业务点有些要求在事务中，有些要求在事务之外。如果每次新的需求出现，都在原有系统直接进行修改，那么不但可能破坏原有的业务，而且可能导致系统可维护性变差。提供扩展点功能，将把扩展逻辑和主体业务逻辑进行有效的隔离，能够彻底解决上面的问题。

E：支撑业务敏捷。支付宝的交易流具有流程类型多，流程过程繁杂的特点，业务流程每个月都会提出多种新的交易业务，同时我们的业务从单一交易业务流向整合型业务流发展。因此，我们引入了BPM相关的技术和工具，帮助我们方便，灵活的组合服务，定制流程。

• 数据架构师

负责数据相关的架构，例如：数据库，文件数据，分布式数据架构，数据切分，数据规划，统一数据视图，数据分析，数据备份等方面的内容。
（和技术架构师一道，构件类似google的文件存储、Ebay的统一数据访问层等，对于系统伸缩性、性能、迈入云计算等价值巨大）
制定数据相关的规范、标准流程。
审核系统、项目中数据相关的内容。

• 技术架构师

关注整体系统架构，通过技术架构对业务架构提供支撑；研究基础技术，通用技术；解决系统稳定性、可靠性、性能、一致性、安全性、可用性等；关注生产率。
制定软件设计、开发、测试等方面的标准、规范、指南等。
参与核心系统设计、开发、测试等。
各类规范的审核，review。
评估系统规模，风险等。
【说明：】系统分析员不是技术架构师，但技术架构师能够胜任系统分析员的职责。

• 业务架构师

关注业务架构，对公司战略，客户需求，内部需求进行抽象，组织，规划。例如：taobao的B2C、C2C业务，会员业务，评价体系，淘宝交易等业务本质的抽象是什么的研究，业务之间的关系的组织，业务发展的规划等。技术架构师可以通过业务架构来选择技术架构，研究未来支撑业务发展的技术。
关注业务的敏捷性，能够随着战略的变化而变化。
（业务架构师抽象的业务模型，如果能够保证自身数据的一致性，异步性，那么对技术架构师将产生巨大的帮助）
制定业务相关的规范。

• 产品架构师

关注产品架构，利用核心业务包装为不同的产品或产品平台，把公司的核心业务展现给用户，把公司的战略目标具体化。例如：google的WEB搜索产品、手机搜索产品、桌面搜索产品等，同一个搜索业务，包装为不同的产品。产品架构师对产品的规划为业务架构师和同时为技术架构师提供参考。
（产品和业务最终体现了公司的战略，业务是本质，产品是外延，2者缺一不可；产品和业务的规划，发展节奏也代表了公司战略的节奏；产品和业务的发展性也代表了公司战略的持续性）
制定产品相关的规范。

• 首席架构师

制定公司的长期技术路线图。
是公司技术方向和技术组合的重要决策者。

【其它架构师角色】
对于大型网络公司来说，系统管理员的角色的职责并未完全被技术架构师代替。
测试架构师，（看看一个招聘要求：开发和设计测试框架； 纵横全局的考虑产品的功能及非功能需求，设计高精的测试系统；负责研发特定的测试技术；提高整体测试效率；领导公司测试技术的发展和测试策略的方向；前瞻性的考虑未来的版本的测试策略和技术；计划 / 设计测试平台，关注着产品的测试过程；具备测试技术、测试方法学上雄厚的知识。）

【参考】
《谁来当首席架构师？》的相关内容
架构师
10条你不需要软件架构师的理由
软件架构师_21ks.net专题辅导资料
系统分析员、系统架构师、项目经理的区别
什么样的产品人才是人才

• 案例1：等号（==）导致的损失
• 案例2：少传递一个参数导致的损失
• 案例3：默认返回结果的乐观，导致的损失
• 案例4：偶然停止的一个系统，导致系统停机
• 案例5：2个参数没有设置，导致外部系统故障的内部传递
• 案例6：大小写，导致某类业务失败
• 等等

事后看这些问题，发现都很简单，都是由于程序员的粗心导致的。或有有人会说，我们应当允许犯错误，我也是非常认可的，但对于一个企业来说却是非常可怕的，上百个程序员，每人都犯一次这类错误，恐怕企业会有些受不了。
如何规避这些问题哪？

• 制度保证
• 测试保证
• 程序员良好的编程习惯

通过下面几个例子，简单说明良好编程习惯对成长的助推作用。
首先，通过观察，发现上面所列的问题，都是一些编程习惯导致不是很好的人身上发生的。
其次，通过和一些同事交流，虽然他们自己没有遇到过这类问题，但良好的编程习惯帮助他们避免了这类问题以及克服了其它困难。
再次，同样一起进入公司的新毕业的学生，工作时间、加班时间也一样多，1年后，发展却非常不同。通过观察，我发现：排处天然因素，后天因素中很重要的一点就是良好的编程习惯帮助他们获得了成长。
良好的编成习惯包含很多方面，综合我身边这类人的特质，总结了下面几点：

• 坚决按照业界认可（或公司认可）的编程风格编写代码
• 开发、调试、测试过程中遇到的问题，不是简单的解决问题，而是进行深入的思考，挖掘现象背后的基础层面的东西
• 对于别人、外界出现的一些BUG，不是简单的听听即可，而是进行试验，思考
• 对于别人无法解决的BUG，总是尝试各类方法，不解决问题，决不罢休
• 不断总结-〉实践-〉再总结

【参考文章】
程序员如何成长？
程序员的成长从开窍开始系列 一、如何摆脱低级错误的困扰

• 我们完成了SOA化改造。
• 我们的SOA化，已近实现了80%。
• 这次项目是为了实现SOA化，因此要请有这方面经验的公司来实施。
• 从技术角度层面来说，我们达到了SOA化的目标。
• 这是我们最后一个SOA个项目
• 等等

如果这些话出自程序员，项目经理等人员，也是无所谓的；如果出自IT管理层的人员，哪就是一种可怕的想法了。因为他把SOA仅仅看作是一次项目了，而没有把它作为战略。这样的后果也是可以预见的，最终本次投资将会失败。
因此，建议那些准备实施SOA的公司，首先回答这个问题：SOA是贵公司的一个战略吗？
为什么要回答这个问题？

1. 从SOA概念来看

关于什么是SOA，我有几篇文章，可以参考（《这些都不是SOA》,《ESB产品升级准备：SOA、ESB、JBI、SCA、OSGI概念再学习、再理解》,《SOA，想说爱你不容易》）。丛概念上可以看出，SOA不少技术问题，它是一种思想，一种架构，因而不可能通过一个项目就把这种思想或架构完全实现；思想也是会发展得，今天的思想在明天或许就会不适应。

2. 从SOA目标来看

SOA的目标是解决业务敏捷性问题。如今，大环境复杂多变，任何一个公司都不敢说自己的业务就是这几个、自己的业务会一直不会变，很多企业，在很短的周期内，就会推出各类产品（特别是服务类企业，例如：银行、互联网企业等）。只有那些能够快速适应变化，主动寻求变化的企业才能够生存下来，发展起来，例如：会跳舞的大象IBM，IT行业最大的特色就是变化快、发展快，如果IBM的业务不能敏捷的适应这种变化，它还能跳舞吗？正因为IBM深刻理解了SOA的目标，因而它把SOA看作一种战略–可持续的战略。

3. 从IT管理角度来看

对于IT主管，一定要确保本公司的IT战略是可持续的，不能今天一种想法，明天又看到什么好思想，就换了一种想法，或者换个主管，就彻底换了战略（这种做法，就像我们国内的城市建设，路总是修不好）。既然从一种思路切合到了SOA领域，那么再次切换的成本将会更高，也不可能多种思路同时进行（吃得多，嚼不烂）。此外，谁能保证一次项目就确保几年内业务变化的需要？从我们实施的经验来看，必须持续的进行SOA化，才能确保SOA持续的发挥效果。

4. 从系统分析角度来看

每次项目都要进行系统分析，都是基于当前的业务进行，那么不可避免的就会有一些盲点（从认知的角度看，人不可能一次就抓住事物的本质，何况大多数系统分析员不具有这种能力）和不合理支出。这些问题，只有在实施后一段时间才能发现（我们自己的实践经验）；此外随着补丁的实施，原有的系统已经恶化，和最初的SOA化目标越来越远。此时，如果不能再次用SOA的思想重新审视系统，就将彻底失去了SOA带来的好处。

5. 从技术特征来看

SOA非但不能让系统架构变得简单，反而变得复杂了（系统设计要求变高了、系统部署复杂了、发布复杂了、各类SOA相关技术的引入增加了对人员的要求），这也是为什么要引入SOA治理。从这一点来看，只有持续的SOA化，才能最终发挥SOA技术架构的好处。

再次提醒将要进行SOA化的朋友和已经进行了SOA化的朋友，把SOA当作贵公司的可持续的战略来看，而不要认为它紧紧是一次项目。

• Enum不适合作为通用类的属性来使用

在我们的代码中，我看到如下一个情况，有关类：UserPrincipal，它被整个分布式系统中的所有系统共同使用，从包的放置位置：net.esbzone.comm.security就可以看出它的通用性。突然某天，看到有同学在这个类加入了一个Enum属性，这个Enum属性还是另外一个业务系统B内部定义的一个通用常量【这个常量的确很是通用，表示用户类型】。这个例子，首先导致UserPrincipal与业务系统B产生了紧耦合，间接导致所有系统与业务系统B产生了耦合；其次即使它定义在net.esbzone.comm.security包中，也间接导致UserPrincipal与具体业务产生了关联，会增强外部系统对Enum的耦合度，从而削弱了UserPrincipal的独立性；此外一旦Enum发生变化，所有依赖与它的业务系统都要发生变化，代码依赖级别的变化。
往往，Enum的业务语义太强，与场景的关联性太密切，一旦环境发生了变化，Enum的值就可能发生变化，从而导致使用它的业务域对象也可能要发生变化。
使用Enum作为通用类的属性，制约了该类的通用性。
【注意：】在封闭系统内部是非常适合使用Enum，它会增强代码的可读性，减少维护成本，降低风险。

• Enum不适合作为服务接口的参数来用

首先是序列化的风险。
其次Enum增强了系统的耦合性，如果只是接口耦合，那么可以通过WS，HTTP POST等方式来降耦。如果使用了Enum之后，我们进一步增加了对Enum这种特殊类型的处理【大部分标准化协议和现代变成语言，都支持原子类型，对象类型，集合类型，但对Enum的支持却各有所不同】，这就增加了耦合性。此外，此时对于一个使用者要面对多个服务提供者的时候，如果遇到这种情况就会更加痛苦不堪。
再次，Enum在接口层使用，制约了扩展性。当增加一个新的业务常量时，需要修改Enum，此时它的WSDL文件也会发生变化【这点很头痛】，想到于修改了接口描述文件。
最后，我们从业务协议设计的角度来看，我们需要的只是原子数据类型，而不是Enum这么强的一个对象类型。

1. SRP 单一职责原则
   就一个服务接口而言，应该仅有一个引起它变化的原因。
   职责即为”变化的原因”.
2. ISP 接口隔离原则
   不应该强迫客户依赖于他们不用的方法。接口属于客户，不属于他所在的类层次结构。
   多个面向特定用户的接口胜于一个通用接口。
3. REP 重用发布等价原则
   重用的粒度就是发布的粒度.
4. ADP 无依赖原则
   在包的依赖关系中不允许存在环.
   细节不应该被依赖.
5. IDP(Interface Design Principle)接口设计原则
   规划一个接口而不是实现一个接口。

其它一些可以参考的点：
• 放弃程序级别的OO概念。
• 业务的粒度就是接口方法的粒度。
• 接口方法尽可能简单、清晰、业务含义明确。

在实际应用中，按照这些准则，我总结了一些具体需要需要的点：《SOA实践之：在程序层，服务接口设计的一些准则》【对于这篇文档，会随着实践而不断补充】

【参考资料：】
面向对象设计准则
override, overload, covariance
OO基本概念

服务与业务组件的定义：
1. 业务组件：最小的业务逻辑单元，例如：密码验证组件、登录组件。
2. 服务：业务模块提供给外部的核心业务逻辑，服务组合业务组件。例如：修改密码服务，会使用密码组件的验证服务，也会使用登录组件的修改密码服务。

【说明：】可否密码验证组件的功能合并到登录组件哪？可以的，此处之所以单独分离，与我们提供多种密码验证机制有关，登录组件对应的业务并未完全涵盖密码验证组件的功能。

• 服务接口的方法，禁止重名（overload特性）。大多数序列化工具【例如：XFire】对重名方法进行处理时，都不可能避免的存在或多或少的问题。为了减少麻烦，还是放弃OO的这一特性，或者在面向服务领域，重载本身就不是一个特性。
• 服务接口的方法，避免返回异常【我们是禁止异常，包括业务异常、系统异常】。这个要求看起来违反了一些对象设计的原则，从实际使用角度来看，具有如下好处：很多工具对异常序列化很容易出现错误；一不小心，外部使用者还会产生异常依赖；需要外部使用者自己把异常翻译为业务语义【从业务角度来说不是件好事情】。
• 服务接口必须有清晰的文档说明，对于常量性质的参数，要列出支持的常量值。
• 服务接口尽可能把查询和业务方法分离【非必须】。好处是使用AOP时简单方便，对于查询方法进行特殊处理时也比较方便，例如：与cache整合、与搜索引擎整合、与特殊权限要求进行整合（例如，对返回信息按照权限进行过滤）等。
• 服务接口参数排列按照如下原则：操作主体对象或ID，业务参数{…}，环境参数。
  例如：verifyPassword(String operatorId, String password, ServiceContext serviceContext)
  operatorId是操作主体的ID。
  Password是密码。
  serviceContext是环境参数。
• 业务处理类接口，返回值可以采用统一对象模式。例如：ServiceResult：

  public class ServiceResult<T> implements Serializable {

  private static final long serialVersionUID = 760567785564620157L;

  private boolean isSuccess;

  private String resultCode;

  private T resultObject;

  public boolean isSuccess() {
  return isSuccess;
  }

  public void setSuccess(boolean isSuccess) {
  this.isSuccess = isSuccess;
  }

  public String getResultCode() {
  return resultCode;
  }

  public void setResultCode(String resultCode) {
  this.resultCode = resultCode;
  }

  public T getResultObject() {
  return resultObject;
  }

  public void setResultObject(T resultObject) {
  this.resultObject = resultObject;
  }
  }
  采用这种模式，实际是按照协议的角度进行设计，所有服务按照统一的包装模式返回。

• 服务接口的参数避免使用Object类型，集合类型要指定具体对象类型。原因：当使用Object时，使用者获取到WSDL文件时，不知道该传递什么业务数据，如果是其它语言的调用者，更无法理解了；这类接口设计违反了业务SOA的原则，暗含着如下潜台词：业务上不明确的，不清晰的。
• 服务接口避免使用集合类型，尽可能使用数组类型。
• 服务接口中使用枚举的原则：如果是对外界发布，避免使用枚举；如果使用者众多，避免使用枚举；如果是内部几个专用系统使用，可以考虑使用枚举，可以参考《枚举产生的系统耦合性》。【文档的清晰化，可以化解常量参数不明确的问题】
• 服务接口避免设计成面向数据的操作，例如：updateStatus。这类接口，通常包含太多的业务含义，甚至没有业务含义，需要外部使用者去理解业务内部的细节，否则无法进行操作。这也是我们设计服务接口时，需要特别注意的地方，不要让外部使用理解业务内部是如何存储的，结构是什么样的，这样会导致业务耦合度过高，服务内部发生重构，变化时，外部使用也需要进行变化。
• 服务接口层建议设计一个统一的模板框架，来处理性能分析、特殊参数处理（例如：ServiceContext）、事务处理、异常处理、日志处理、事件处理、审计处理等具有共性的行为。
• 服务接口的方法名避免以：is，get开头，用find，check等来代替之，避免Java序列化工具把该类当作Java Bean进行处理。
• 业务组件中异常的要求：所有的业务组件，如果发现违法业务原则的地方，需要中断程序的执行，那么throw统一业务异常，该业务异常可以借鉴如下方式设计：
  public class ComponentException extends Exception {

  private static final long serialVersionUID = -6900280471536579015L;

  private ErrorCodeEnum code = null;

  public ComponentException ErrorCodeEnum code) {
  super();
  this.code = code;
  }

  public ComponentException ErrorCodeEnum code, Throwable e) {
  super(e);
  this.code = code;
  }

  public ErrorCodeEnum getCode() {
  return code;
  }

  public void setCode(ErrorCodeEnum code) {
  this.code = code;
  }
  }

  坏处：从异常名看不出明确的业务语义。
  好处：避免服务层需要捕获多种异常；业务语义通过ErrorCodeEnum返回到业务层。

• 业务组件内部尽可能少的进行事务处理【除非有特殊的需求】、异常处理【除外业务组件自身组合了外部的业务服务，此时需要处理异常】。
  好处：统一由服务层进行处理，可以避免事务处理的错误。不进行异常处理，可以避免异常转义时，出现信息丢失；此外，如果使用了统一异常，那么就更不能在业务组件内部进行异常处理了，否则会发生原始业务限制规则被丢失的可能。

对于一些基本原则，可以参考《SOA实践之：在程序层，面向服务的设计准则探讨》一文。

使用方，推荐使用代理模式来使用外部服务。
1、可以进行一些特殊处理，例如：网络异常处理，远程性能评估等
2、对内部提供重业务层面的方法，屏蔽环境参数
3、外部服务接口发生变化时，或许修改一处就能够满足变化
4、如果要对传输层、安全进行定制时，会非常方便

【参考资料】
模块分解原理的探索
Interface Design — Best Practices in Object-Oriented API Design in Java
Part 1: Exploring the development, interfaces, and operation semantics of services
Part 2: Exploring the development, interfaces, and operation semantics of services