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