很多人对SOA的理解就是分层、模块化、面向对象。。。这种理解对不对后面再说。先看一些问题：

我今天看了一个开发团队的开发工程包结构，部分类的命名及组织产生了如下印象：

• 每个usecase是一根根烟囱
• 烟囱与烟囱之间连模型都没有共享。其实业务模型是有设计的，主要是实现模型没有保持业务模型的结构特征，全部成了“值对象”，开发人员天天把这些值对象叫做领域对象。
• 有三层，是Struts帮忙定义的，三层分别根据usecase分包

这也是我们宣称的SOA系统！！！！连最基本的模型设计、模块设计、分层设计都没做好，难怪年年重构、年年完成不可能完成的任务！！！我确信这种重构、这种不可能完成的任务还会年年持续下去！！！

究竟什么是符合SOA风格的系统？先看看SOA宗师IBM的一篇文章：

http://www.ibm.com/developerworks/cn/architecture/ar-soastyle/

我来总结一下。

SOA能达到什么目的：

1.实现业务与IT的一致性；

2. 创建更灵活的反应更敏捷的IT基础设施；

3. 简化集成实现；

SOA要怎么做？

1. 从应用程序到流程和服务。消除应用程序，将软件系统创建为一组由业务流程进行协调的交互服务。每个服务实现企业上下文中定义的特定业务目标或功能，业务流程表示必须实现的业务解决方案。这个讲的比较抽象，我的解读就是服务表示一个最细粒度的业务目标或功能，由业务流程来编排这些服务，实现更大粒度的业务目标或功能，业务流程也是服务。注意，这里隐式的定义了服务的概念，服务是自治的，可替换的，可被多个流程编排的，不耦合流程上下文的，是直接面向业务目标或功能的，不是一个公共函数库，服务不是封装了数据和方法的类。
2. SOA的服务基于业务资源（对象）定义，不支持操作者的执行上下文，而是支持业务资源（对象）。这里的业务资源是指业务实体。业务实体也是来自业务的。所以，SOA能保证IT与业务的一致性。

别再说你的应用程序或烟囱遵循SOA的架构风格！

确定系统需求即确定系统用例。方法以根据业务用例实现场景分析为输入，分析每个系统Actor的系统用例。每个系统用例一定是一个完整的事件流，注意业务用例和系统用例的区别，业务用例是一个完整的业务目标，而系统用例是一个完整的事件流，是业务目标中的一个环节，如客户代表申请开户是一个完整的系统用例，但不是一个完整的业务目标，其包括多个页面操作。

3.11 用例实现分析

对每个系统用例，识别其可能的实现路径，每个实现路径就是一个用例实现，然后针对每个用例实现，分析人机交互，使用活动图绘制用例实现场景。

3.12 分析模型

使用分析对象，实现所有的用例实现场景，识别出三种分析对象。在这个过程中，也可以建立界面原型，和客户进一步达成需求的一致理解。分析模型是需求到设计的桥梁，分析类的层次高于设计实现，需求通过分析类转成计算机语言。后续做系统设计的时候，可直接将分析模型转换成设计模型。

在考虑分析模型的过程中，有可能识别出一些公共模块，比如开户、销户过程中都会有一些业务规则校验，需要引入规则引擎的支持，那么类似规则引擎这样的公共模块需要添加到逻辑架构中去。

3.13 非功能性需求设计

以性能为例讲一下对非功能性需求设计的过程。

1、确定性能目标：要支持多少用户、多少在线用户、多少并发操作、操作响应时间要求等；

2、以一个简单的三层架构为起点，根据性能目标，识别瓶颈。比如，如果数据库撑不住，那么需要考虑最佳的分库设计，如果是逻辑层撑不住，则要考虑负荷分担，状态同步的逻辑层方案设计，如果操作响应时间要求很高，则可根据不同场景，分析其操作的数据的读写特点，采用合适的缓存方案。如要支撑高并发低时延的大数据量查询，Twitter就采用了垂直缓存，raw缓存的设计方案。

3、验证性能设计。抽取典型场景，实现一个prototype来验证性能设计是否满足性能目标。

在质量属性设计中，如果需要新增模块，则需要修改逻辑架构。

有一些约束类需求也是非常重要的，不能遗漏分析。

经过这一个阶段，我们能够得到一个比较完整的逻辑架构，运行架构、开发架构、物理架构、数据架构的输入了。剩下的工作就是编档的工作了。

3.14 架构编档

有了上面的工作作为铺垫，编档就非常容易了，这个就不细讲了。

分别针对上节中业务用例视图中的每一个用例，分析该业务用例在实际工作中是如何做的，一般使用业务活动图来表述业务场景。在这个阶段，有几点需要特别注意的地方：

1、关注参与业务用例的各个参与者是如何协同的，如一个简化的用户开户的流程就是填写营业员提交开户订单-》主管审批订单-》施工人员履行订单；

2、对一个业务用例，如果有不同的实现路径，需要做不同的场景分析。例如，用户订购产品，分网上订购和营业厅订购这两种场景，两个场景大不相同；

3、场景的步骤粒度：用户的一个完整操作目的，如用户开户，则用户填写订单是一个步骤，而不用细化到用户取单、拿笔填单等；

3.5 产生业务对象模型

针对每个业务用例，根据业务用例场景，分析该用例中涉及的业务实体，并绘制业务对象模型图。

3.6 产生业务用例实现视图

业务用例实现指业务用例的一种实现路径，一个业务用例实现对应着一个业务用例场景。业务用例实现视图是表述业务用例实现的视图。

3.7 分析业务用例实现场景

业务用例实现场景着重描述如何通过人机交互来完成业务，是业务用例场景的具体化。一般用活动图来表述人机交互流程。这里每个步骤的粒度是人与系统或系统与人的一次交互。

3.8 领域建模

领域模型是描述特定问题域的对象及其相互关系。领域模型对业务对象做了进一步的精化。领域建模的步骤如下：

1、确定问题域：如CRM中的客户模型比较关键，我们决定对其进行领域建模，则需要将设计客户业务实体的用例全部识别出来；

2、领域建模：逐一分析涉及到操作客户模型的业务用例场景，识别领域对象以及对象之间的关系；

3、验证领域模型：使用序列图作为工具，基于领域模型来编排实现各业务场景，如果能实现，证明领域模型ok。

领域对象跟业务对象有区别，我认为，业务对象不是领域对象。业务对象来自于业务用例，是业务中客观存在的，而领域对象是对业务对象做进一步抽象、精化后的结果，是人对业务的主观认识，这就是为什么不同厂商的产品模型会不一样的原因，而且并不是所有的领域对象都是根据业务对象分析而来的。比如，某CRM产品面向全球市场，可定制能力是关键，为提升可定制性，需要构建一个快速开发框架，这个快速开发框架也是软件系统的一部分，也是有领域模型的，但是它的领域模型跟业务对象没半点关系。

3.9 产生逻辑架构草稿

通过上述步骤，我们已经有了部分领域模型，针对每一个可直接映射到业务对象一级的领域对象，可规划相应的业务模块，如有开户订单，那么可以有订单管理，有客户管理等。业务模块的划分粒度可依据大概的工作量而定，保证最低级别的业务模块的工作量是大致均匀的。这仅仅是一个建议，可以根据项目的实际情况决定。

基于上述的成果，我们还只能产出一个逻辑架构的草稿，因为我们还没有分析质量属性，后续对质量属性做设计的时候，还有可能会引入新的模块。比如要让业务流程可快速编排、定制，我们希望引入工作流，那么逻辑架构中也要引入一个工作流模块。

待续。。。

究竟什么是订单?

订单作为一个业务Actor皆可感知的重要业务实体，其是脱离IT系统而存在的，IT系统所做的仅是将其在软件系统中以对象的形式表现出来，不能依据系统实现，改变订单的定义。要正确的给订单下定义，须忘掉IT系统，从业务的角度给出定义。

企业一般会有售前，售后，销售，服务等部门，而订单是产生在销售活动中的，表示客户对企业产品或服务的一次订购。依此理解，退换货是服务，不是订单，而充值是订单。走不走流程，仅仅是订单实施的方式。

这个案例告诉我们，系统的业务模型，要从业务的视角来建，IT系统是将业务模型用软件概念来表述，不能改变业务概念。