很多人对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的架构风格！

如何解决上文提到的鉴定标准中的问题呢？我认为答案就是MDD。

用一个实际的例子来表述一下思路：

在CRM系统有个订单处理模块，其提供了订单管理、订单流程执行、工单管理等功能，营业员通过界面提交一个订单请求，如果订单请求通过业务规则的校验，则会创建一个订单对象，订单对象的创建会触发订单流程的创建，订单流程流转的过程中，会在各个节点创建工单，也会调用其它子系统开通服务，比如调用物流发货。订单流程完成后，订单对象的状态也完成。实际的系统比这个要复杂，这里仅仅为了阐述思路，做适当的简化。

从上面的例子，我们可以识别出几个模型:订单、工单、订单流程，订单、工单、订单流程都是stateful的、其state的变更会导致其它对象的状态变更或者服务的执行。

在展现层，展现各个模型是有章法的，比如创建订单的界面总是一样的，处理工单的界面也总是一样的，展现订单的界面也总是一样的。因此，我们可针对指定的对象的某种需要展现的状态，提供合适的展示构件（WEB TAG）来展示它。

在持久层，因为对象总是持久化到一张表当中的，因此，可用一些ORM的框架来持久化对象，而不是开发人员针对每个场景去写SQL，复杂的关联查询可以使用类HQL。

各对象之间的关联操作通过事件驱动。

举一个订单创建的例子：

1、开发做的工作：

    1）使用元数据定义订单的数据结构，包含持久化元数据、基本属性元数据、字典元数据；

    2）定义订单状态机，以及状态变迁的规则；

    3）建模订单处理流程；

    4）定义订单请求处理规则流，并发布为一个受理订单请求的服务；

    5）开发订单创建界面，使用订单WEB构件来展示订单对象；

    6）定义事件，以及事件的监听服务；

2、系统执行流程：

    1）营业员打开订单创建界面，系统获取订单对象的元数据，生成订单创建页面；

    2）营业员点击订单创建界面的提交按钮，调用受理订单请求的服务；规则流执行，如果规则校验错误，则返回错误，如果成功，则创建订单，返回成功；

    3）因创建订单，导致订单的状态变为创建状态，触发订单创建事件；

    4）订单创建的监听服务流程服务接收到事件，触发订单处理流程的创建；

    5）流程执行的过程中编排第三方系统服务；流程执行结束后，触发订单流程结束事件，流程结束事件的监听服务订单管理接收到事件，触发状态机变迁，订单状态变为完成。

上述开发做的工作全部可通过配置完成。后续如果增删字段，修改元数据即可，要增删改业务规则，调整业务规则即可，要调整实体状态，修改实体状态机即可。

业务平台要致力于对状态机、业务流程、SEP、元数据、领域化的WEB构件的实现，并将其有机整合。

写的比较乱，过几天再整理一下。。。

就如同变化多端的八卦卦象是由乾、兑、离等8个基本卦象组成，万事万物是由数种原子构成，形态各异的高楼大厦是由砖头和砂浆砌成，应用也有构成其的“元”，即构件。

业务应用是分层的，典型的分层是展现层、流程层、服务层、数据持久层，每一层次的关注点都不同，构件也不相同，比如一个业务逻辑层的构件输出的数据，会通过展现层的构件来展现在界面上。且各层之间的贯通黏合（如MVC中的Controller层就是黏合逻辑），通常要耗费比较多的开发精力，一个好的业务平台，除了在各层次分别提供可复用的构件，需要能够减少各层黏合的工作量。

面向特定领域的业务平台的易用度与其适用面是鱼和熊掌的关系，针对特定领域，要越易用，则平台能力就要越面向特定领域，则越不通用，导致适用面越窄。因此，一个好的平台，要注意分层，比如分成通用的构件和领域化的构件。业务用户可按需使用。同时，还需要在各层次开放定制能力，供业务用户在各层提供领域构件。

现在的产品交付都是解决方案级的交付，解决方案由多个系统或子系统构成，一个部门，一个项目组通常只是提供解决方案中的一个部件，负责端到端的业务功能中的一个环境，因此，需要支持构件的组装，以形成更大粒度的构件，支撑软件复用与集成。

开发一个子系统粒度的构件通常是一件很复杂的事情，如CRM，需求琐碎、变化频繁、不同客户要求不尽相同，如果缺乏一个好的支撑平台，人力成本会很高，TTM也会很长，因此，一个好的业务平台，也需要能够支撑快速的构件开发、定制。

解决构件的组装和集成，已经有比较成熟的技术了，如ESB、SCA等，IBM、Oracle等大厂商都有提供集成化的开发环境和执行环境。但如何支撑构件的开发这块，各大厂商也有支撑，比如在展现层，Oracle有ADF，在流程层，IBM和Oracle都提供了BPM，在service层，IBM和Oracle提供了规则引擎，VMWare的Spring，在持久层，Oracle提供了Toplink，还有就JBOSS大名鼎鼎的Hibernate。所有前面提到的这些都是业务无关的技术部件，且各层之间的靠业务开发人员自己来黏合，还是不够领域化。因此，一个业务平台，仅仅去重复制造IBM、Oracle造过的轮子，是完全没有竞争力的（这里不算成本）。面向特定领域，评判一个业务平台是否优秀的标准是：

1、是否提供了丰富的领域构件？

2、是否能够节省业务开发人员黏合各层的工作量？

3、提供了什么样的机制来应对需求变化？比如有的客户要求多加个字段、加个校验，有的客户要求少个字段、少个校验等等。

待续。。。

接下来的推导分为两个阶段，第一阶段先推导支撑技术，第二阶段再推导以什么样的开发方式将这些支撑技术串起来，达到快速开发的目的。

下表中列出了对上面的核心组成要素（数据+服务）的一些支撑技术：

下面在列一些辅助支撑技术，这些技术是为了让企业应用这些大厦能够构建的更快，毕竟盖房子，有了水泥和砖是不够的，还要有扁担，簸箕等等。