目前很多互聯網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網關就可以了