目前很多互联网app项目，都是采用这样的一个基本项目结构：即由后端提供Restful的api接口，然后供前端例如IOS、Android或者H5端去调用，如图：

在这种结构下，后台的代码分层常规一般会有两种做法：

方式1：后台代码分为web层、service层、dao层，其中service层直接暴露成dubbo服务供Resuful去调用

方式2：后台代码分为web层、service层、dubbo服务层，dao层，其中服务层即是dubbo的服务，服务层供Service层调用

上述两种方式中方式2在分层上相对要合理些，好处是在service中调用dubbo，可以单元测试，并且比较容易

但更合理的方式是在Service层和dubbo服务层之间再抽象出一层，可以把这层暂且称为服务适配层，这一层可以起到这样的作用：

1. 屏蔽掉Service层对dubbo服务层的耦合和依赖

2.  某个dubbo服务有时会提供给不同的Service去调用，这个就有点象是数据库中的某张表会提供给不同的业务场景去使用，所以这个服务适配层的作用就有点类似于Dao层的作用了，它首先可以把Service层传递的数据转换成dubbo服务需要的参数形式，并且可对dubbo服务执行完成后的结果数据进行检查校验以确认接口是否调用成功，然后再返回给Service层。这样一来Service层的代码会更干净些。

---

更好的方式应该是在dubbo的服务层之上应提供一个API网关，由API网关负责对dubbo服务的访问（可以考虑用泛化的方式去调用），这样所有的业务系统如果需要调用dubbo服务，就以Restful的方式调用API网关就可以了