前言
微服務(wù)開發(fā)中很重要的rpc功能妄迁，實(shí)現(xiàn)上不管是springcloud還是dubbo方式蛾茉，代碼結(jié)構(gòu)上看垦江，都是分為api層和service層嗓化。
前者就是純粹接口定義+數(shù)據(jù)對象棠涮，輕量打包。后者就是對api的實(shí)現(xiàn)刺覆。
然后注入api严肪，然后各自去注冊中心獲取需要的服務(wù)實(shí)現(xiàn)。
結(jié)構(gòu)上一般如下：
一谦屑、api或者interface
這個module就是包含接口定義和數(shù)據(jù)定義驳糯，沒有任何實(shí)現(xiàn)。注意：也不能引用其他業(yè)務(wù)單元的api
1氢橙，api
實(shí)際操作中會用業(yè)務(wù)（比如訂單order）關(guān)鍵字命名酝枢，定義一個xxxApi，只有接口的定義悍手。
2帘睦、數(shù)據(jù)對象
比如BO, DTO或者其他重要枚舉等，復(fù)雜的業(yè)務(wù)操作需要一個模型坦康，或者說就是給1api中提供出入?yún)⒌陌b竣付。
二、service
以springcloud為例滞欠，有如下幾層古胆。
1、controller
這層就是對api的實(shí)現(xiàn)筛璧，主要是對出入?yún)⒌臋z查逸绎，或者從上下文中獲取特定參數(shù)，然后調(diào)用底層服務(wù)進(jìn)行功能實(shí)現(xiàn)夭谤，千萬不可在這一層進(jìn)行復(fù)雜業(yè)務(wù)處理棺牧，這一層不支持事務(wù)回滾。
2沮翔、service層
主要的業(yè)務(wù)實(shí)現(xiàn)層陨帆，這里建議在分為兩層
2.1 基礎(chǔ)服務(wù)層（entityService）
對應(yīng)對entity，對單表的基礎(chǔ)操作采蚀，而且這些操作建議是用api中定義的數(shù)據(jù)對象來進(jìn)行疲牵，而不用entity對象。
可以各種省去entity dto的轉(zhuǎn)化榆鼠。
2.2 聚合服務(wù)層（XXXFacadeService）
就是對2.1 entityService的各種聚合纲爸，這些entityService不止包括自己模塊，也可以引用其他模塊妆够，完成特定的業(yè)務(wù)功能识啦。
3、dao層
現(xiàn)在有很多的orm框架神妹，比如mybatis plus 颓哮，也提供了較好的集成方式，不在展開鸵荠。
4冕茅、sql層
邏輯上其實(shí)沒有這一層，只是物理上它一般放在resource里了蛹找，作為dao實(shí)現(xiàn)的重要組成姨伤。
三、類圖
如圖庸疾，上圖就是一個具體的實(shí)現(xiàn)乍楚。
該類圖中重要的一個補(bǔ)充是，把entityService和bizService的區(qū)分開來届慈。
實(shí)際開發(fā)中徒溪，每個微服務(wù)模塊負(fù)責(zé)人的理解及習(xí)慣有差，無法做到真正的高內(nèi)聚金顿，低耦合词渤。比如你就只需要查詢或者修改其中一個表的某個狀態(tài)，但就是沒有這個接口串绩。
針對這種單表的操作缺虐，其實(shí)是可以定制統(tǒng)一接口，要求統(tǒng)一提供對單表的操作的礁凡。對于復(fù)雜多變的業(yè)務(wù)高氮，也許是未來的，都可以使用這些基礎(chǔ)服務(wù)來操作顷牌。
比如OrderEntityApi 針對Order單表的操作剪芍，OrderCountApi，訂單統(tǒng)計相關(guān)的api窟蓝。
四罪裹、其他補(bǔ)充
不同的狀態(tài)，應(yīng)當(dāng)用枚舉定義。
xxBizUtills,用來做靜態(tài)類的業(yè)務(wù)工具（沒有注入任何springbean状共，且都是publish static）套耕。
xxBizHelper,用來做動態(tài)注入的幫助類（允許注入其他springbean）。
entityService應(yīng)當(dāng)多用對象參數(shù)峡继。爭取最大復(fù)用冯袍。
bizFacadeService 建議多用基礎(chǔ)類型參數(shù)，簡化調(diào)用人的學(xué)習(xí)負(fù)擔(dān)碾牌，重要的是康愤，應(yīng)當(dāng)對業(yè)務(wù)進(jìn)行重要提煉，
cache也在這一層處理舶吗，如果有多個模塊都能調(diào)用這層的某個方法征冷，說明業(yè)務(wù)設(shè)計很精湛了。
待補(bǔ)充誓琼。资盅。。
