后端這個(gè)詞在不同圈子里的含義差別很大。芯片設(shè)計(jì)里有數(shù)字后端游戲開(kāi)發(fā)里有服務(wù)器后端但大多數(shù)時(shí)候我們嘴里說(shuō)的“后端”指的是軟件服務(wù)端——也就是處理接口、寫(xiě)業(yè)務(wù)邏輯、操作數(shù)據(jù)庫(kù)的那部分代碼。這個(gè)領(lǐng)域里分層架構(gòu)是繞不開(kāi)的基礎(chǔ)話題也是很多人的“熟悉又陌生區(qū)”天天寫(xiě)著Controller、Service、DAO但真要問(wèn)一句每一層到底該干什么、不該干什么很多人反而說(shuō)不清楚。這篇文章就是一次完整的后端分層架構(gòu)知識(shí)梳理。我會(huì)把分層的本質(zhì)、每層職責(zé)邊界、工程落地模板、前后端協(xié)作時(shí)的對(duì)應(yīng)關(guān)系以及面試高頻追問(wèn)和實(shí)戰(zhàn)排查技巧都過(guò)一遍。適合正在做后端開(kāi)發(fā)、準(zhǔn)備梳理技術(shù)體系、或者剛接手一個(gè)分層混亂項(xiàng)目的朋友照著文章里的思路去整理自己項(xiàng)目基本夠用。1. 分層架構(gòu)的真正價(jià)值別把Controller當(dāng)成萬(wàn)能收納盒1.1 分層的本質(zhì)是管理依賴方向很多項(xiàng)目之所以代碼越寫(xiě)越亂不是因?yàn)槊灰?guī)范也不是因?yàn)槿鄙僮⑨尪且驗(yàn)橐蕾嚪较蚴Э亓恕Ｊ裁词且蕾嚪较蚓褪恰罢l(shuí)可以調(diào)用誰(shuí)”的規(guī)則。在經(jīng)典的分層架構(gòu)里Controller只能依賴ServiceService只能依賴DAO反過(guò)來(lái)就不允許。這個(gè)規(guī)則看著簡(jiǎn)單但一旦被打破問(wèn)題就來(lái)了。舉個(gè)我真實(shí)見(jiàn)過(guò)的例子有個(gè)訂單模塊的Controller為了省事直接調(diào)用了用戶模塊的DAO去查用戶信息。剛開(kāi)始覺(jué)得很簡(jiǎn)單后來(lái)用戶表加了一個(gè)字段DAO層的方法簽名變了訂單模塊的Controller也要跟著改再后來(lái)用戶模塊從單庫(kù)拆成了分庫(kù)訂單模塊這邊直接崩了。這就是跨層調(diào)用帶來(lái)的后果底層細(xì)節(jié)不再是底層被你當(dāng)成了公共工具到處用任何數(shù)據(jù)庫(kù)變更都會(huì)像多米諾骨牌一樣波及所有調(diào)用方。可以拿廚房來(lái)類(lèi)比。Controller是傳菜口Service是廚房里的廚師長(zhǎng)DAO是負(fù)責(zé)采購(gòu)和倉(cāng)庫(kù)的人。如果顧客在傳菜口直接問(wèn)倉(cāng)庫(kù)有沒(méi)有食材看似快了但倉(cāng)庫(kù)的入庫(kù)規(guī)則一變傳菜口也得跟著改整個(gè)餐廳的流程就亂了。分層不是把代碼分類(lèi)放好那么簡(jiǎn)單它的本質(zhì)是用“單向依賴”把變化隔離在每一層內(nèi)部讓上層的變化不輕易連累到底層底層的變化也不至于穿透到上層。1.2 常見(jiàn)分層結(jié)構(gòu)的選型對(duì)比后端的“層”沒(méi)有絕對(duì)標(biāo)準(zhǔn)常見(jiàn)的方案有兩類(lèi)。一類(lèi)是經(jīng)典三層Controller、Service、DAO。Spring Boot項(xiàng)目、Ruoyi這類(lèi)后臺(tái)管理系統(tǒng)用的基本都是這個(gè)套路。三層結(jié)構(gòu)簡(jiǎn)單直觀中小型項(xiàng)目選它準(zhǔn)沒(méi)錯(cuò)。另一類(lèi)是在三層基礎(chǔ)上再拆細(xì)比如在Service和DAO之間插入Repository/Infrastructure層或者參照DDD的寫(xiě)法分成Interface、Application、Domain、Infrastructure四層。這個(gè)方案的優(yōu)點(diǎn)是把領(lǐng)域邏輯單獨(dú)收口復(fù)雜度高、業(yè)務(wù)規(guī)則重的系統(tǒng)能扛得住缺點(diǎn)是理解成本高小團(tuán)隊(duì)硬上容易變成只會(huì)抄結(jié)構(gòu)的“偽DDD”。對(duì)比維度經(jīng)典三層細(xì)粒度四層DDD風(fēng)格學(xué)習(xí)成本低新人都能快速上手中高需要理解領(lǐng)域建模適合規(guī)模中小型項(xiàng)目、管理系統(tǒng)業(yè)務(wù)復(fù)雜、規(guī)則多變的大型系統(tǒng)層間職責(zé)Controller、Service、DAO分工清晰進(jìn)一步拆分應(yīng)用層與領(lǐng)域?qū)舆^(guò)度設(shè)計(jì)的風(fēng)險(xiǎn)低高業(yè)務(wù)不復(fù)雜時(shí)容易空轉(zhuǎn)還要說(shuō)清楚一點(diǎn)非Java技術(shù)棧也一樣有分層思想。Python FastAPI寫(xiě)典型的后端項(xiàng)目通常也是router - service - repository的模式只是名字不叫Controller叫Router而已Node.js后端用Express或NestJSNestJS干脆在框架層面就定義了Controller、Service、Module。所以分層不是Spring Boot專(zhuān)屬它是一種通用工程思想框架只是幫我們把分層固化成了約定。2. 每層職責(zé)邊界寫(xiě)代碼前先定好“誰(shuí)該干什么”2.1 Controller層只做協(xié)議適配不碰業(yè)務(wù)規(guī)則Controller層在傳統(tǒng)三層里是最靠近用戶的一層它做的事情應(yīng)該非常窄接收HTTP請(qǐng)求、解析入?yún)?、做?jiǎn)單的參數(shù)格式校驗(yàn)、調(diào)用Service、把返回結(jié)果組裝成響應(yīng)對(duì)象。但現(xiàn)實(shí)項(xiàng)目里Controller經(jīng)常被寫(xiě)成一坨“萬(wàn)能盒子”。有人喜歡在Controller里寫(xiě)復(fù)雜if判斷有人直接把查詢邏輯堆在里面還有人把多個(gè)Service的操作揉在一個(gè)接口里做一個(gè)“組合業(yè)務(wù)”。這些做法其實(shí)都是在慢性透支代碼的可維護(hù)性。我自己寫(xiě)Controller的習(xí)慣是遵循一個(gè)鐵律Controller里不出現(xiàn)業(yè)務(wù)判斷不出現(xiàn)對(duì)DAO的調(diào)用不出現(xiàn)任何和數(shù)據(jù)庫(kù)有關(guān)的代碼。一個(gè)比較正常的Controller方法大概長(zhǎng)這樣接收DTO簡(jiǎn)單校驗(yàn)之后轉(zhuǎn)給Service然后包裝成統(tǒng)一響應(yīng)結(jié)構(gòu)返回。至于這個(gè)操作是新增還是更新、數(shù)據(jù)怎么校驗(yàn)、庫(kù)存夠不夠都是Service層的事。這里有一個(gè)很容易被忽略的細(xì)節(jié)不要拿實(shí)體類(lèi)直接當(dāng)接口的入?yún)⒑统鰠ⅰ?shí)體類(lèi)是數(shù)據(jù)層的映射直接暴露給前端會(huì)有幾個(gè)問(wèn)題。第一數(shù)據(jù)庫(kù)字段會(huì)被原樣泄露出去比如用戶表里的內(nèi)部標(biāo)記字段跟著響應(yīng)出去了第二實(shí)體類(lèi)里的字段和接口需要的字段經(jīng)常不一致前端拿到的對(duì)象要么冗余要么缺失第三如果實(shí)體類(lèi)和表結(jié)構(gòu)強(qiáng)綁定表加字段就等于接口響應(yīng)加字段接口穩(wěn)定性無(wú)從談起。正確的做法是用DTO/VO作為Controller層和Service層之間的傳遞對(duì)象把實(shí)體類(lèi)擋在數(shù)據(jù)層內(nèi)部。提示接口的HTTP狀態(tài)碼不要濫用。狀態(tài)碼適合表達(dá)請(qǐng)求本身的狀態(tài)比如200表示成功、400表示參數(shù)錯(cuò)誤、401表示未登錄業(yè)務(wù)上的失敗比如“余額不足”“訂單已關(guān)閉”更適合放在統(tǒng)一響應(yīng)結(jié)構(gòu)里的業(yè)務(wù)code字段中交給前端統(tǒng)一彈提示。2.2 Service層業(yè)務(wù)編排與事務(wù)邊界的主戰(zhàn)場(chǎng)Service層是整個(gè)分層的核心也是業(yè)務(wù)邏輯真正的落腳點(diǎn)。一個(gè)Service方法通常對(duì)應(yīng)一個(gè)完整的業(yè)務(wù)動(dòng)作比如創(chuàng)建訂單、發(fā)起退款、更新用戶信息。它要做的事情包括參數(shù)校驗(yàn)Controller只做格式校驗(yàn)業(yè)務(wù)校驗(yàn)交給Service、調(diào)用一個(gè)或多個(gè)DAO、組織業(yè)務(wù)規(guī)則、控制事務(wù)邊界。事務(wù)邊界放哪里是很多新手容易糾結(jié)的問(wèn)題。Spring里Transactional常見(jiàn)放法是放在Service層的方法上這是有道理的Controller不該管事務(wù)因?yàn)镠TTP請(qǐng)求的處理不只是數(shù)據(jù)庫(kù)操作事務(wù)開(kāi)在這里粒度太寬DAO層做事務(wù)又太細(xì)一個(gè)業(yè)務(wù)動(dòng)作要拆成多個(gè)DAO操作時(shí)就管不住了。放在Service層正好是一個(gè)業(yè)務(wù)動(dòng)作一個(gè)事務(wù)粒度剛剛好。但是事務(wù)里不能什么都做。我踩過(guò)一個(gè)大坑下單流程里先插入訂單數(shù)據(jù)然后在同一個(gè)事務(wù)里調(diào)用第三方短信接口發(fā)通知。結(jié)果第三方接口響應(yīng)特別慢數(shù)據(jù)庫(kù)連接被這個(gè)事務(wù)一直占著連接池很快被耗盡整個(gè)接口直接雪崩。后來(lái)改成先落庫(kù)把短信消息丟到消息表/消息隊(duì)列里異步發(fā)送才把問(wèn)題解決。事務(wù)里不能做耗時(shí)操作和遠(yuǎn)程調(diào)用這不是什么高深理論而是資源占用的現(xiàn)實(shí)約束。事務(wù)會(huì)鎖住數(shù)據(jù)庫(kù)連接和部分行記錄時(shí)間長(zhǎng)了你對(duì)外部服務(wù)的等待全都會(huì)轉(zhuǎn)嫁成數(shù)據(jù)庫(kù)的壓力。另外Service層也容易出現(xiàn)另一種極端把DAO搬到Service里來(lái)或者一個(gè)Service類(lèi)寫(xiě)了兩三千行。一個(gè)Service類(lèi)如果明顯超過(guò)合理規(guī)模就要考慮按業(yè)務(wù)動(dòng)作拆類(lèi)或拆模塊而不是硬往一個(gè)類(lèi)里塞。判斷標(biāo)準(zhǔn)很粗暴你找一個(gè)不熟悉項(xiàng)目的人來(lái)看這個(gè)類(lèi)他能不能在十分鐘內(nèi)說(shuō)清楚這個(gè)類(lèi)負(fù)責(zé)什么。說(shuō)不清楚就是該拆了。實(shí)操心得Service層盡量不要捕獲異常后只打日志然后返回null。寧可把異常向上拋?zhàn)尳y(tǒng)一異常處理器去兜底。否則調(diào)用方拿到null后還得猜這是業(yè)務(wù)上的“沒(méi)有數(shù)據(jù)”還是系統(tǒng)真的出了故障很容易把真實(shí)問(wèn)題掩蓋掉。2.3 DAO/Repository層持久化細(xì)節(jié)的收口DAO層負(fù)責(zé)和數(shù)據(jù)庫(kù)打交道CRUD、SQL映射、事務(wù)中與數(shù)據(jù)源相關(guān)的底層操作。這一層存在的主要意義是把持久化細(xì)節(jié)SQL怎么拼、表結(jié)構(gòu)長(zhǎng)什么樣、怎么分頁(yè)與上面的Service層隔離開(kāi)。用MyBatis還是JPA本質(zhì)上是數(shù)據(jù)訪問(wèn)策略的選擇。MyBatis的SQL完全由自己控制適合復(fù)雜查詢多、對(duì)SQL調(diào)優(yōu)有要求的場(chǎng)景JPA/Hibernate更偏對(duì)象建模讓開(kāi)發(fā)者以對(duì)象視角操作數(shù)據(jù)但復(fù)雜的動(dòng)態(tài)查詢寫(xiě)起來(lái)也比較別扭。分層架構(gòu)對(duì)這兩個(gè)選擇是中立的因?yàn)闊o(wú)論底層用哪個(gè)Service層看到的都只是一個(gè)數(shù)據(jù)訪問(wèn)接口實(shí)現(xiàn)細(xì)節(jié)被DAO層吸收掉了。這里要提一個(gè)常見(jiàn)的認(rèn)知誤區(qū)很多人為了讓“分層嚴(yán)謹(jǐn)”給Service層和DAO層都強(qiáng)行加接口然后寫(xiě)一堆實(shí)現(xiàn)類(lèi)。其實(shí)除非有多個(gè)實(shí)現(xiàn)比如一個(gè)實(shí)現(xiàn)走M(jìn)ySQL一個(gè)實(shí)現(xiàn)走Redis緩存或者有明確的需要遠(yuǎn)程暴露接口的場(chǎng)景否則在單體項(xiàng)目里為Service和DAO寫(xiě)接口完全是多余的抽象。DAO層還有一個(gè)邊界要注意DAO只負(fù)責(zé)“一個(gè)數(shù)據(jù)操作”或“一組緊密相關(guān)的數(shù)據(jù)操作”不要在DAO層寫(xiě)業(yè)務(wù)規(guī)則判斷。比如“查詢所有未支付且超過(guò)30分鐘的訂單”是SQL條件沒(méi)問(wèn)題但“如果用戶是VIP則不發(fā)短信”這種業(yè)務(wù)判斷放在Service層而不是DAO層。3. 實(shí)操落地一個(gè)真實(shí)后端項(xiàng)目的分層模板3.1 工程結(jié)構(gòu)與包命名我見(jiàn)到過(guò)很多分層項(xiàng)目代碼里每一層的職責(zé)很清楚但包結(jié)構(gòu)是亂的——有人按先分層再分業(yè)務(wù)有人按先業(yè)務(wù)再分層兩種方式交替出現(xiàn)在同一個(gè)項(xiàng)目里。這種混亂其實(shí)比代碼本身的邏輯問(wèn)題更難改。對(duì)大多數(shù)項(xiàng)目我更推薦“先按業(yè)務(wù)模塊分包再在模塊內(nèi)分層”。做單體應(yīng)用時(shí)把同一業(yè)務(wù)的所有層放在一個(gè)包路徑下找代碼非?？臁１热缫挠唵瘟鞒踢M(jìn)order包里面controller、service、dao一清二楚。如果是多個(gè)Java后端項(xiàng)目合并的場(chǎng)景業(yè)務(wù)模塊的邊界就顯得特別重要合并后的歸屬規(guī)則越清晰后面越省心。一個(gè)可復(fù)用的包結(jié)構(gòu)示例Java Spring Boot項(xiàng)目com.company.project ├── common // 公共工具、統(tǒng)一響應(yīng)結(jié)構(gòu)、全局異常處理 ├── order │ ├── controller │ ├── service │ ├── dao │ └── dto ├── user │ ├── controller │ ├── service │ ├── dao │ └── dto └── config // 全局配置相關(guān)這里有幾個(gè)細(xì)節(jié)值得說(shuō)。第一common包會(huì)被所有模塊依賴但反過(guò)來(lái)絕對(duì)不允許。第二模塊之間的調(diào)用盡量走對(duì)方的Service接口而不是直接調(diào)對(duì)方的DAO否則又退回到跨層依賴的坑里了。第三DTO是每一層的輸入輸出邊界不要所有對(duì)象都放一個(gè)entity包里否則到了后期“DTO”和“實(shí)體”兩個(gè)包會(huì)龐大到?jīng)]法用。3.2 對(duì)象傳遞與跨域、冪等、重復(fù)提交處理很多后端項(xiàng)目在實(shí)際跑起來(lái)之后繞不開(kāi)三個(gè)和分層強(qiáng)相關(guān)的問(wèn)題跨域、接口響應(yīng)結(jié)構(gòu)、重復(fù)提交/冪等。這三個(gè)問(wèn)題看起來(lái)是“配置”問(wèn)題但落點(diǎn)其實(shí)都和分層有關(guān)。先說(shuō)跨域。前后端分離項(xiàng)目里前端跑在8080端口后端跑在9090端口瀏覽器直接訪問(wèn)后端接口就會(huì)被同源策略擋住。解決方式有幾種后端加CORS配置、網(wǎng)關(guān)層統(tǒng)一處理、Nginx反向代理。Spring Boot里最省事的做法是寫(xiě)一個(gè)全局的CORS配置類(lèi)把允許的來(lái)源、方法、請(qǐng)求頭都配好。注意一個(gè)小細(xì)節(jié)allowCredentials(true)和allowedOrigins(*)不能同時(shí)使用如果前端請(qǐng)求需要帶上Cookie來(lái)源必須寫(xiě)具體域名不能寫(xiě)通配符。再說(shuō)統(tǒng)一響應(yīng)結(jié)構(gòu)。接口返回不要一會(huì)兒返回一個(gè)對(duì)象一會(huì)兒返回一個(gè)數(shù)組一會(huì)兒又直接拋異常給前端。我會(huì)定義一個(gè)統(tǒng)一的響應(yīng)包裝類(lèi)里面至少包含業(yè)務(wù)code、message和data三個(gè)字段。這樣前端的Axios攔截器就只用處理這一種結(jié)構(gòu)成功時(shí)取data失敗時(shí)根據(jù)code彈對(duì)應(yīng)提示不需要每個(gè)接口單獨(dú)寫(xiě)一套狀態(tài)判斷。最后說(shuō)重復(fù)提交。前端按鈕置灰只是用戶體驗(yàn)層面的兜底用戶弱網(wǎng)環(huán)境下的超時(shí)重試、移動(dòng)端雙擊、機(jī)器人腳本等場(chǎng)景前端根本約束不住。后端要保證冪等常用的方案是“請(qǐng)求唯一ID 服務(wù)端去重”前端在發(fā)起關(guān)鍵操作時(shí)生成一個(gè)唯一的冪等鍵或者后端生成后返回給前端后端在Service層入口處先查這個(gè)冪等鍵是否已經(jīng)處理過(guò)處理過(guò)就直接返回上一次的結(jié)果沒(méi)處理過(guò)才繼續(xù)往下走。這個(gè)冪等校驗(yàn)的邏輯放哪一層我認(rèn)為核心是放在Service層邊緣而不是Controller層。Controller層校驗(yàn)的是“請(qǐng)求格式對(duì)不對(duì)”Service層才真正關(guān)心“這個(gè)業(yè)務(wù)請(qǐng)求有沒(méi)有處理過(guò)”。配合數(shù)據(jù)庫(kù)層的唯一索引做兜底才能做到即使校驗(yàn)邏輯被并發(fā)穿透庫(kù)里也不會(huì)出現(xiàn)兩條重復(fù)單。提示跨域配置和統(tǒng)一響應(yīng)結(jié)構(gòu)這類(lèi)“橫切關(guān)注點(diǎn)”應(yīng)該放在全局基礎(chǔ)設(shè)施里不要散落在各個(gè)Controller方法中。這個(gè)位置在工程上通常屬于Web層的公共配置不參與任何具體業(yè)務(wù)邏輯。3.3 多個(gè)Java后端項(xiàng)目合并時(shí)的分層歸位后端同學(xué)應(yīng)該都遇到過(guò)合并項(xiàng)目的場(chǎng)景公司里幾個(gè)后端小項(xiàng)目因?yàn)闃I(yè)務(wù)調(diào)整需要合并成一個(gè)。合并之前每個(gè)項(xiàng)目都有自己的Controller、Service、DAO甚至各自都有工具類(lèi)和常量類(lèi)怎么合才不亂我的經(jīng)驗(yàn)是先立規(guī)矩再做動(dòng)作。第一步把公共依賴梳理出來(lái)工具類(lèi)、統(tǒng)一響應(yīng)、異常處理、公共配置這些收進(jìn)common模塊。第二步把業(yè)務(wù)代碼按業(yè)務(wù)模塊歸隊(duì)同一個(gè)業(yè)務(wù)的所有層放一起類(lèi)似上面說(shuō)的包結(jié)構(gòu)。第三步是消除反向依賴比如A項(xiàng)目原本調(diào)了B項(xiàng)目的DAO現(xiàn)在A的業(yè)務(wù)代碼就應(yīng)該改調(diào)B模塊的Service接口否則合并之后A直接依賴B的DAO等于把跨層調(diào)用從一個(gè)項(xiàng)目帶進(jìn)了新項(xiàng)目。合并過(guò)程中最常遇到的坑是Bean沖突和包掃描混亂。多個(gè)項(xiàng)目都定義了Constants類(lèi)、Result類(lèi)類(lèi)名一樣Spring掃描時(shí)或者編譯時(shí)就會(huì)沖突。處理方式通常有兩種統(tǒng)一改造成同一個(gè)公共類(lèi)或者用不同的包名隔離。我建議優(yōu)先統(tǒng)一因?yàn)橥?lèi)在合并后會(huì)帶來(lái)長(zhǎng)期的認(rèn)知負(fù)擔(dān)每次看代碼都得先確認(rèn)是哪一個(gè)Constants。合并項(xiàng)目的過(guò)程其實(shí)是一次“分層體檢”。哪個(gè)模塊職責(zé)不清、哪個(gè)模塊依賴方向反轉(zhuǎn)、哪個(gè)模塊公共邏輯散落全部會(huì)因?yàn)楹喜⑦@個(gè)動(dòng)作而暴露出來(lái)。如果能借這個(gè)機(jī)會(huì)順手理清楚后續(xù)維護(hù)成本會(huì)低很多。4. 分層架構(gòu)對(duì)協(xié)作和面試的真正影響4.1 和產(chǎn)品經(jīng)理、前端對(duì)齊接口時(shí)的分層思維很多人覺(jué)得分層是純技術(shù)話題和產(chǎn)品經(jīng)理沒(méi)法聊。但其實(shí)分層思維在跨角色溝通里特別有用。產(chǎn)品經(jīng)理關(guān)心的“功能”在開(kāi)發(fā)眼里其實(shí)是“某個(gè)模塊的某個(gè)業(yè)務(wù)動(dòng)作”而要評(píng)估這個(gè)動(dòng)作的改動(dòng)量就是看它會(huì)穿透哪幾層只改Controller接口返回結(jié)構(gòu)、還是只改Service業(yè)務(wù)規(guī)則、還是連DAO和表結(jié)構(gòu)都要?jiǎng)訑?shù)據(jù)層想清楚這件事就能給出相對(duì)靠譜的工作量評(píng)估不會(huì)被一句“這不就是加個(gè)字段的事嗎”給問(wèn)住。以前端對(duì)接為例前端真正關(guān)心的是“路由是什么、入?yún)⑹鞘裁?、出參是什么、哪些狀態(tài)碼代表什么含義”。這些信息本質(zhì)上就是Controller層的協(xié)議內(nèi)容。內(nèi)部分多少層、SQL怎么寫(xiě)、表長(zhǎng)什么樣前端完全不需要知道。所以后端在梳理分層架構(gòu)的同時(shí)也是在給外部協(xié)作劃邊界Controller層是對(duì)外協(xié)議Service層對(duì)內(nèi)業(yè)務(wù)協(xié)議值不值得變動(dòng)成為評(píng)估前后端聯(lián)調(diào)工作量的主要依據(jù)。平時(shí)我在接口評(píng)審的時(shí)候習(xí)慣先不討論實(shí)現(xiàn)細(xì)節(jié)而是先把路由、請(qǐng)求參數(shù)、響應(yīng)字段、錯(cuò)誤碼和狀態(tài)碼逐一對(duì)齊確認(rèn)這份“協(xié)議”沒(méi)有歧義再回落到各自的實(shí)現(xiàn)層里去編碼。這個(gè)習(xí)慣幫我把很多返工擋在了開(kāi)發(fā)之前。4.2 完整業(yè)務(wù)在分層中的落點(diǎn)以電子簽署流程為例分層講抽象很多人聽(tīng)著覺(jué)得明白了但真要寫(xiě)一個(gè)新業(yè)務(wù)時(shí)又不知道從哪里下手。用一個(gè)相對(duì)完整的業(yè)務(wù)來(lái)舉例可能會(huì)更直觀。拿電子簽名/電子簽署流程來(lái)說(shuō)用戶在前端發(fā)起一份合同簽署真實(shí)的業(yè)務(wù)鏈路落在后端各層是什么樣呢Controller層接收簽署請(qǐng)求入?yún)⑹呛贤琁D、簽署人信息、簽署坐標(biāo)等它做的事情是把這些參數(shù)交給Service然后返回一個(gè)表示“簽署任務(wù)已創(chuàng)建”的結(jié)果。Service層是核心編排校驗(yàn)合同狀態(tài)是否允許簽署校驗(yàn)當(dāng)前用戶是否屬于簽署人創(chuàng)建簽署記錄調(diào)用第三方電子簽SDK生成簽署鏈接或發(fā)起簽署流程。DAO層負(fù)責(zé)把簽署記錄、合同狀態(tài)變更持久化到數(shù)據(jù)庫(kù)。第三方平臺(tái)的異步回調(diào)簽署完成、簽署失敗進(jìn)來(lái)后又是一個(gè)新的入口由Controller接收通知Service更新業(yè)務(wù)狀態(tài)DAO落庫(kù)。如果把這一步業(yè)務(wù)放在一個(gè)分層混亂的項(xiàng)目里會(huì)出現(xiàn)什么情況最后數(shù)碼還是要找Service業(yè)務(wù)邏輯散在Controller里數(shù)據(jù)庫(kù)操作又散在Service里。每新增一個(gè)簽署環(huán)節(jié)都要同時(shí)改好幾個(gè)文件而且沒(méi)人能說(shuō)清邊界在哪。分層在這里真正的價(jià)值是讓你能準(zhǔn)確回答“這個(gè)需求影響哪些類(lèi)”這個(gè)問(wèn)題。4.3 面試八股分層架構(gòu)相關(guān)的高頻追問(wèn)與回答思路分層架構(gòu)本身也是后端面試?yán)锏某？拖嚓P(guān)的問(wèn)題通常不會(huì)直接問(wèn)“分層是什么”而是從各種角度試探你理解得深不深。梳理幾個(gè)我見(jiàn)過(guò)的高頻問(wèn)題為什么需要分層核心是為了控制依賴方向、隔離變化、降低維護(hù)成本。單說(shuō)“為了代碼清晰”不夠要能舉出依賴方向失控導(dǎo)致的具體問(wèn)題。Controller、Service、DAO的職責(zé)各是什么這是基礎(chǔ)中的基礎(chǔ)但被追問(wèn)的通常是細(xì)節(jié)比如“參數(shù)校驗(yàn)放Controller還是Service”“統(tǒng)一異常處理在哪一層”。事務(wù)邊界應(yīng)該放在哪一層為什么答案是Service層理由涉及粒度控制、連接資源管理、遠(yuǎn)程調(diào)用不能包在事務(wù)里。循環(huán)依賴怎么解決常見(jiàn)的有構(gòu)造器注入、Lazy、抽公共邏輯到新類(lèi)、用事件機(jī)制解耦。面試時(shí)能說(shuō)出“先審視設(shè)計(jì)再談工具手段”會(huì)更出彩。項(xiàng)目里能直接用Entity作為接口返回嗎這是個(gè)陷阱題標(biāo)準(zhǔn)回答是不建議理由包括字段暴露、接口不穩(wěn)定、無(wú)法控制序列化視圖等?？缬騿?wèn)題是誰(shuí)的職責(zé)前后端分離場(chǎng)景下后端負(fù)責(zé)允許跨域常見(jiàn)方案CORS配置、網(wǎng)關(guān)層統(tǒng)一處理也要能說(shuō)清為什么瀏覽器有同源策略限制。這些問(wèn)題的背后其實(shí)都指向同一個(gè)能力你是否理解“依賴方向”和“職責(zé)邊界”。把這兩點(diǎn)想透無(wú)論八股題怎么變你都能用自己的話接住。5. 常見(jiàn)問(wèn)題與避坑實(shí)錄5.1 Service事務(wù)失效的典型場(chǎng)景和排查方法事務(wù)問(wèn)題在分層實(shí)戰(zhàn)中出現(xiàn)頻率極高而且很多是Spring代理機(jī)制引起的。最常見(jiàn)的失效方式是同一個(gè)類(lèi)內(nèi)部調(diào)用方法A標(biāo)注了Transactional方法B沒(méi)有被標(biāo)注A在內(nèi)部直接調(diào)BB事務(wù)不會(huì)生效。原因是Spring事務(wù)基于代理內(nèi)部調(diào)用this.b()走的不是代理對(duì)象注解也就沒(méi)被解析。解決辦法是把獨(dú)立事務(wù)方法拆到另一個(gè)類(lèi)或者注入自身/使用代理對(duì)象來(lái)完成調(diào)用。另一種常見(jiàn)問(wèn)題是異常被吞。事務(wù)方法里寫(xiě)了try...catch捕獲之后不拋出事務(wù)自然認(rèn)為一切正常已經(jīng)執(zhí)行到一半的寫(xiě)操作不會(huì)回滾。如果確實(shí)需要在事務(wù)方法里捕獲異常做一些記錄記得處理完后再拋出異?；蛘吒挠肨ransactionTemplate手動(dòng)控制事務(wù)邊界。還有事務(wù)不回滾不是異常類(lèi)型導(dǎo)致的。Spring默認(rèn)只對(duì)RuntimeException和Error回滾checked exception默認(rèn)不會(huì)觸發(fā)回滾。所以自定義業(yè)務(wù)異常最好是繼承RuntimeException或者在Transactional里顯式配置rollbackFor Exception.class。排錯(cuò)技巧懷疑事務(wù)失效時(shí)先看調(diào)用鏈?zhǔn)遣皇墙?jīng)過(guò)了Spring代理再看有沒(méi)有捕獲異常后吞掉最后看異常類(lèi)型。按這個(gè)順序排查大部分問(wèn)題五分鐘內(nèi)就能定位。5.2 循環(huán)依賴與跨層依賴的典型報(bào)錯(cuò)“The dependencies of some of the beans in the application context form a cycle”是Spring項(xiàng)目里一個(gè)很經(jīng)典的啟動(dòng)報(bào)錯(cuò)。循環(huán)依賴最常出現(xiàn)在Service層A Service依賴B ServiceB Service又反過(guò)來(lái)依賴A Service。很多人的第一反應(yīng)是用Lazy或用setter注入繞過(guò)這些手段確實(shí)能跑但更應(yīng)該先反思的是這兩個(gè)Service為什么非得互相持有對(duì)方如果A和B是因?yàn)闃I(yè)務(wù)上互相調(diào)用太多導(dǎo)致的循環(huán)優(yōu)先把它們公共依賴的部分抽取出來(lái)放在一個(gè)新的Service或公共能力里如果是A需要監(jiān)聽(tīng)B的事件可以用Spring事件機(jī)制讓A不直接依賴B。設(shè)計(jì)上的解耦比注入方式上的繞過(guò)更能避免后續(xù)維護(hù)里的一堆隱藏坑。跨層依賴的問(wèn)題在項(xiàng)目合并或迭代中也很常見(jiàn)比如Service層里又寫(xiě)了一套JdbcTemplate操作Controller直接注入Mapper。這些問(wèn)題不像循環(huán)依賴會(huì)立刻報(bào)錯(cuò)而是慢慢發(fā)酵成“改一處壞別處”的隱性技術(shù)債。好的分層架構(gòu)會(huì)讓依賴關(guān)系從代碼結(jié)構(gòu)上被限制住而不是靠每個(gè)人的自覺(jué)。5.3 性能問(wèn)題中的分層視角N1查詢說(shuō)到性能問(wèn)題我見(jiàn)過(guò)不少案例都和分層使用不當(dāng)相關(guān)典型就是N1查詢。什么是N1比如Service層先調(diào)用DAO查出訂單列表1次查詢?nèi)缓蟊闅v每個(gè)訂單去查對(duì)應(yīng)的用戶信息N次查詢。如果訂單有100條就是101次數(shù)據(jù)庫(kù)請(qǐng)求。這種問(wèn)題在ORM框架下特別容易發(fā)生用JPA時(shí)如果實(shí)體關(guān)聯(lián)配置不當(dāng)很容易在遍歷時(shí)觸發(fā)每行額外查詢。排查N1的思路很清晰開(kāi)SQL日志統(tǒng)計(jì)一次接口調(diào)用實(shí)際產(chǎn)生了幾條SQL。如果一條接口請(qǐng)求打出幾十上百條SQL基本可以斷定有N1問(wèn)題。解決方式通常有三種DAO層用一次批量查詢代替循環(huán)查庫(kù)用MyBatis的嵌套結(jié)果映射或關(guān)聯(lián)查詢?cè)赟QL層面解決改代碼結(jié)構(gòu)避免在循環(huán)里去調(diào)用單條查詢方法。這里有一個(gè)分層相關(guān)的點(diǎn)N1問(wèn)題往往發(fā)生在Service層“循環(huán)調(diào)DAO”這個(gè)動(dòng)作里。所以好的分層實(shí)踐還會(huì)鼓勵(lì)每個(gè)DAO方法“面向批量”設(shè)計(jì)比如提供selectByIds而不是讓調(diào)用方循環(huán)調(diào)selectById。這是Data Access層對(duì)自己職責(zé)的一種優(yōu)化意識(shí)。5.4 響應(yīng)結(jié)構(gòu)、跨域和序列化相關(guān)的踩坑記錄跨域配置的坑前面提到過(guò)一部分再補(bǔ)充幾個(gè)我實(shí)際遇到的細(xì)節(jié)。第一是允許的來(lái)源和憑證的沖突如果配置里同時(shí)出現(xiàn)allowedOrigins(*)和allowCredentials(true)Spring會(huì)在啟動(dòng)時(shí)直接報(bào)錯(cuò)或?qū)е抡?qǐng)求失敗解決辦法是顯式列出允許的來(lái)源域名。第二是預(yù)檢請(qǐng)求的問(wèn)題前端攜帶著自定義Header或非簡(jiǎn)單Content-Type發(fā)請(qǐng)求時(shí)瀏覽器會(huì)先發(fā)一個(gè)OPTIONS預(yù)檢請(qǐng)求如果后端沒(méi)有正確處理OPTIONS就會(huì)看到“CORS error”但后端日志里又一片安靜。第三是生產(chǎn)環(huán)境要確認(rèn)跨域配置是否面向特定域名全放開(kāi)在安全審查時(shí)多少是個(gè)風(fēng)險(xiǎn)點(diǎn)。統(tǒng)一響應(yīng)結(jié)構(gòu)也容易踩序列化的坑。比如用Jackson時(shí)如果某個(gè)DTO里有個(gè)null字段默認(rèn)會(huì)序列化成field: null如果整體結(jié)構(gòu)變來(lái)變?nèi)デ岸私馕鼍蜁?huì)變得很脆弱。建議在團(tuán)隊(duì)里約定一套穩(wěn)定的響應(yīng)協(xié)議成功時(shí)固定結(jié)構(gòu)、失敗時(shí)固定結(jié)構(gòu)字段要不要排除null通過(guò)全局配置統(tǒng)一處理。最后提醒一句跨域、統(tǒng)一響應(yīng)、全局異常處理這些屬于Web層的基礎(chǔ)設(shè)施關(guān)注點(diǎn)。不要在每一個(gè)Controller里單獨(dú)適配全局處理一次后續(xù)所有接口自動(dòng)受益。分層架構(gòu)的收益很多時(shí)候就體現(xiàn)在這些“一次處理好處處不用管”的橫切能力上。分層的價(jià)值在做對(duì)的時(shí)候其實(shí)感覺(jué)不到它的存在。你會(huì)覺(jué)得改需求挺順的、新同學(xué)接項(xiàng)目也沒(méi)那么痛苦、加字段改接口都有明確的位置。但一旦分層亂了每一步改動(dòng)都會(huì)讓人煩躁這種感受經(jīng)歷過(guò)的人自然懂。我自己在整理或重構(gòu)項(xiàng)目時(shí)最看重的從來(lái)不是用了什么高深架構(gòu)而是這一層依賴邊界是不是清楚改一個(gè)業(yè)務(wù)功能時(shí)能不能快速說(shuō)出要?jiǎng)幽膸讉€(gè)文件。把這個(gè)基本功做扎實(shí)比追逐任何花哨的架構(gòu)名詞都重要。