在谈SOA参考架构的时候一般都会谈到服务分层，即原子服务，组合服务和流程服务。服务可以不断的朝上进行组合和编排以满足业务流程的需要。越朝上服务本身的重用性会下降，但是对业务的支撑和匹配更好。

1.简单的服务组合和编排可以在ESB里面完成

2.多个服务的编排更推荐在BPEL里面完成，例如Oracle-SOA提供的BPEL设计器，支持SCA/SDO标准

SOA参考架构的一个核心思想就是只要底层的业务能力组件建设好了，后续的所有业务和流程需求都应该可以通过服务组合，服务编排或流程编排来完成，而不是再单独建设新的业务系统。这才是真正打破业务系统越建越多，形成大量信息孤岛的关键。

真正系统都建设完成了，再通过SOA集成平台来解决系统间的集成问题，往往SOA思想就很难落地，更多的只是一个接口平台而已。

在谈组件化或者微服务架构下微服务模块划分的时候，可以看到在轻量的微服务架构下是不会有比较重的ESB服务编排或BPEL流程编排能力的。那么在这种情况下这些能力本身应该有相对独立的微服务模块完成。

基于SOA服务分层的思路，微服务模块或者组件应该分为三类，从底朝上分别是：

1. 数据类：核心基础数据或共享数据，核心提供数据存储和访问能力。

2. 业务类：主要是单业务处理，本身也存在单据，但是单据处理最终目的是形成数据到数据类模块。

数据类模块是最底层的模块，核心是基础数据和共享数据。包括了供应商管理模块，产品和物料模块，价格库模块等。这些可以称为数据类模块，一个是支撑上层业务，一个还需要跨业务共享数据给其它系统。

业务类模块即类似采购计划，采购项目，采购请购，供应商认证等都可算作业务模块，仅仅是完成一类业务，最终会形成数据存储到数据类模块。比如供应商认证，最终认证通过的供应商会进入到供应商库;采购请购最终完成的请购单会形成采购订单。

对于采购订单应该算作数据类模块，核心是采购订单数据是需要共享的核心动态数据。

对于跨多个业务模块和数据模块协同才能完成的应用，应该划入到更加上层的流程模块，流程模块既可以跨多个业务模块协同的完整业务流程;也可以是跨多模块的BI分析类应用。其核心的判断标准是跨没跨多个业务模块。

业务模块一方面可以是完成某类业务办理，同时业务模块也可以是对多个数据模块的数据整合，提供整合后的数据服务能力。这也是上一篇我谈领域服务层谈到关键，一方面是业务整合，一方面是数据整合。

再和SOA服务分层做下对应可以看到，对于数据类模块更多的是提供最底层的原子服务能力，对于业务模块则提供组合服务和服务编排能力，对于流程模块则对应到BPM流程编排和端到端流程实现能力。