1. T3 Code到底是什么別把它當(dāng)成多一個(gè)文件夾很多團(tuán)隊(duì)一提到“T3 Code”——也就是三層架構(gòu)Three-Tier Architecture下的編碼實(shí)踐第一反應(yīng)就是Controller、Service、DAO各建一個(gè)包目錄分層就完事了。我在不少項(xiàng)目里見(jiàn)過(guò)這種理解結(jié)果是代碼確實(shí)分了三個(gè)文件夾但業(yè)務(wù)邏輯還是糊成一團(tuán)Controller里塞了上千行Service里全是SQL拼串DAO層反倒成了擺設(shè)。這個(gè)現(xiàn)象太典型了所以我想先花點(diǎn)篇幅說(shuō)清楚T3 Code到底在解決什么問(wèn)題。三層架構(gòu)的核心從來(lái)不是目錄長(zhǎng)什么樣而是一條依賴(lài)紀(jì)律。表現(xiàn)層只負(fù)責(zé)接收輸入和返回結(jié)果業(yè)務(wù)層只負(fù)責(zé)業(yè)務(wù)規(guī)則和流程編排數(shù)據(jù)層只負(fù)責(zé)跟數(shù)據(jù)庫(kù)打交道。每一層的代碼只能依賴(lài)下一層不能跨層調(diào)用、不能回頭依賴(lài)、更不能把職責(zé)互相滲透。換句話(huà)說(shuō)這不是“多建幾個(gè)包”的事而是讓團(tuán)隊(duì)在寫(xiě)每一行代碼的時(shí)候都清楚地知道這行代碼屬于哪個(gè)層它該不該出現(xiàn)在這里。我最早接觸三層架構(gòu)是七八年前做傳統(tǒng)企業(yè)級(jí)項(xiàng)目的時(shí)候那時(shí)候還沒(méi)有Spring Boot用的是Spring MVC加MyBatis分層是強(qiáng)制性的。說(shuō)實(shí)話(huà)當(dāng)時(shí)沒(méi)覺(jué)得分層多厲害反而覺(jué)得麻煩一個(gè)簡(jiǎn)單的增刪改查要寫(xiě)三層類(lèi)還要各寫(xiě)各的方法代碼量翻倍。但后來(lái)接手了一個(gè)沒(méi)有分層的遺留系統(tǒng)一個(gè)方法里從頁(yè)面參數(shù)解析到JDBC連接全部干完改一個(gè)字段要順著調(diào)用鏈翻十幾個(gè)地方我才意識(shí)到三層架構(gòu)保護(hù)的不是寫(xiě)代碼的人而是后面維護(hù)代碼的人也包括三個(gè)月后的自己。T3 Code適合誰(shuí)參考我覺(jué)得主要兩類(lèi)人。一類(lèi)是剛?cè)胄?、正在學(xué)Spring Boot或者其他Web框架的同學(xué)你需要一個(gè)標(biāo)準(zhǔn)答案來(lái)建立代碼邊界感另一類(lèi)是團(tuán)隊(duì)里負(fù)責(zé)技術(shù)規(guī)范的人你需要在“過(guò)度設(shè)計(jì)”和“一把梭”之間找一條可落地的線(xiàn)。這篇文章會(huì)圍繞三層如何拆分、每層怎么寫(xiě)出花、事務(wù)和異常怎么處理、以及我踩過(guò)的坑來(lái)展開(kāi)盡量把實(shí)際項(xiàng)目里能碰到的問(wèn)題都聊一遍。2. 每一層該怎么拆落代碼前先過(guò)一遍腦2.1 表現(xiàn)層只做翻譯不做計(jì)算表現(xiàn)層的核心職責(zé)是兩件事把用戶(hù)的輸入變成業(yè)務(wù)層能理解的對(duì)象把業(yè)務(wù)層的結(jié)果變成用戶(hù)能看的格式。我常跟團(tuán)隊(duì)說(shuō)一句話(huà)Controller里面不要出現(xiàn)if/else不要出現(xiàn)任何業(yè)務(wù)判斷不要出現(xiàn)new一個(gè)業(yè)務(wù)對(duì)象然后手動(dòng)set一堆字段這種操作。如果一段邏輯在Controller里沒(méi)有三行以上大概率是放錯(cuò)位置了。實(shí)際操作中Controller應(yīng)該做的事情非常機(jī)械接收HTTP請(qǐng)求解析參數(shù)做基礎(chǔ)的格式校驗(yàn)比如必填項(xiàng)、長(zhǎng)度限制、枚舉合法性調(diào)用一個(gè)Service方法傳參盡量用單個(gè)DTO或BO對(duì)象不要三五個(gè)離散參數(shù)滿(mǎn)天飛把Service返回的數(shù)據(jù)組裝成VO或Response對(duì)象返回給前端如果你發(fā)現(xiàn)Controller里開(kāi)始出現(xiàn)“根據(jù)用戶(hù)類(lèi)型判斷調(diào)哪個(gè)Service”、“計(jì)算某個(gè)金額再傳給Service”這類(lèi)邏輯那就要警惕了。表現(xiàn)層一旦開(kāi)始做業(yè)務(wù)決策后續(xù)前端需求一變改的就是Controller而Controller是暴露給外部的門(mén)面改動(dòng)成本遠(yuǎn)高于內(nèi)部層。2.2 業(yè)務(wù)層業(yè)務(wù)邏輯的家但不是萬(wàn)能垃圾桶業(yè)務(wù)層是T3 Code里最復(fù)雜的一層也是團(tuán)隊(duì)分歧最大的地方。我說(shuō)一個(gè)常見(jiàn)的現(xiàn)象Service里所有方法都喜歡以save、update、delete命名方法體里就是一堆數(shù)據(jù)存取。這種寫(xiě)法不是錯(cuò)但它把業(yè)務(wù)層降級(jí)成了數(shù)據(jù)層的殼業(yè)務(wù)規(guī)則全散落在Controller或者SQL里。真正的業(yè)務(wù)層應(yīng)該負(fù)責(zé)三塊內(nèi)容業(yè)務(wù)規(guī)則比如下單時(shí)要校驗(yàn)庫(kù)存、要計(jì)算優(yōu)惠、要判斷用戶(hù)等級(jí)流程編排先調(diào)哪個(gè)倉(cāng)儲(chǔ)方法、后調(diào)哪個(gè)倉(cāng)儲(chǔ)方法、是否需要事務(wù)事務(wù)邊界哪些操作必須同生共死哪些操作允許部分失敗舉個(gè)例子下單這個(gè)操作。數(shù)據(jù)層只需要提供“查庫(kù)存”“扣庫(kù)存”“創(chuàng)建訂單”“寫(xiě)入訂單明細(xì)”這幾個(gè)原子能力。業(yè)務(wù)層要做的是先查庫(kù)存夠不夠夠則扣減再創(chuàng)建訂單主表和明細(xì)表最后返回訂單號(hào)。這個(gè)編排過(guò)程如果放在Controller里那多個(gè)入口Web端、App端、批量腳本各自實(shí)現(xiàn)一套邏輯必然漂移如果放在數(shù)據(jù)層里那數(shù)據(jù)層就被迫理解“下單”這個(gè)業(yè)務(wù)概念復(fù)用性也廢了。業(yè)務(wù)層的命名也是一個(gè)經(jīng)驗(yàn)點(diǎn)。我一般不用save這種萬(wàn)能動(dòng)詞而是用業(yè)務(wù)動(dòng)詞createOrder、cancelOrder、updateShippingAddress。這樣一眼就能看出這個(gè)方法是干嘛的也好寫(xiě)單元測(cè)試。你想想測(cè)試人員看到一個(gè)createOrder方法很自然就能列出測(cè)試用例庫(kù)存不足、庫(kù)存剛好、重復(fù)提交、優(yōu)惠金額為負(fù)……但如果叫save還得翻方法體才知道它在干什么。2.3 數(shù)據(jù)層老老實(shí)實(shí)跟數(shù)據(jù)庫(kù)打交道數(shù)據(jù)層的職責(zé)最簡(jiǎn)單也最容易跑偏只做數(shù)據(jù)的讀寫(xiě)不做業(yè)務(wù)判斷。Repository或DAO里面就應(yīng)該是findById、selectByCondition、insert、updateStatus這類(lèi)方法。我在實(shí)踐中的一個(gè)習(xí)慣是數(shù)據(jù)層的方法命名盡量以SQL語(yǔ)義來(lái)定而不是業(yè)務(wù)語(yǔ)義。比如不要叫checkInventoryAndDeduct而是拆成selectStockForUpdate和deductStock。為什么因?yàn)闃I(yè)務(wù)層可能需要“查庫(kù)存”而不一定要“扣庫(kù)存”比如預(yù)校驗(yàn)場(chǎng)景。如果數(shù)據(jù)層把業(yè)務(wù)動(dòng)作寫(xiě)死在方法里業(yè)務(wù)層就被數(shù)據(jù)層的設(shè)計(jì)綁架了。還有一個(gè)容易忽略的點(diǎn)數(shù)據(jù)層的參數(shù)對(duì)象盡量使用專(zhuān)門(mén)的Query對(duì)象或DTO不要直接把業(yè)務(wù)層的BO往Repository里傳更不要傳實(shí)體類(lèi)讓SQL去猜。一來(lái)是解耦二來(lái)是防止意外更新。我見(jiàn)過(guò)太多代碼在Repository里updateById(entity)然后entity里一個(gè)不小心帶了創(chuàng)建時(shí)間字段把創(chuàng)建時(shí)間也給改了。用專(zhuān)門(mén)的更新字段對(duì)象就能從結(jié)構(gòu)上避免這種低級(jí)事故。3. 把一個(gè)訂單模塊跑通完整實(shí)操記錄3.1 先定邊界再寫(xiě)代碼很多人寫(xiě)三層代碼容易陷入“先建包后寫(xiě)類(lèi)”的慣性但正確的姿勢(shì)是先定邊界。我拿一個(gè)最典型的訂單模塊舉例這個(gè)模塊在電商項(xiàng)目里幾乎人人都會(huì)碰到。開(kāi)始編碼前我會(huì)先寫(xiě)一份簡(jiǎn)單的邊界清單貼在IDE的TODO里或者在接口文檔里寫(xiě)清楚表現(xiàn)層接口POST /api/orders入?yún)橄聠握?qǐng)求體出參為訂單號(hào)和總金額業(yè)務(wù)層動(dòng)作校驗(yàn)用戶(hù)狀態(tài)、校驗(yàn)庫(kù)存、計(jì)算應(yīng)付金額、創(chuàng)建訂單、扣減庫(kù)存、記錄日志數(shù)據(jù)層原子操作查詢(xún)商品庫(kù)存、扣減庫(kù)存、插入訂單主表、插入訂單明細(xì)表、插入操作日志表這份清單不需要寫(xiě)得多詳細(xì)但能保證寫(xiě)代碼時(shí)每個(gè)方法都知道自己該放在哪一層。等這些邊界確定了再開(kāi)始建類(lèi)、寫(xiě)方法思路會(huì)順暢很多。很多項(xiàng)目代碼亂根源不是不會(huì)分層而是跳過(guò)了這個(gè)“定邊界”的環(huán)節(jié)直接開(kāi)寫(xiě)最后哪里順手就寫(xiě)在哪里。3.2 從用戶(hù)點(diǎn)擊到數(shù)據(jù)落庫(kù)一次完整請(qǐng)求是怎么穿過(guò)三層的咱們順著一次真實(shí)的請(qǐng)求走一遍。用戶(hù)在前端點(diǎn)了“提交訂單”前端POST一個(gè)JSON到/api/orders這個(gè)請(qǐng)求進(jìn)入表現(xiàn)層。Controller先做一個(gè)基礎(chǔ)校驗(yàn)用戶(hù)ID是否存在、商品列表是否為空、收貨地址是否填寫(xiě)。注意這里只做“格式和必填”校驗(yàn)不做“庫(kù)存夠不夠”這種業(yè)務(wù)校驗(yàn)因?yàn)槟菍儆跇I(yè)務(wù)層的事。然后Controller調(diào)用訂單Service的createOrder(CreateOrderRequest request)方法。業(yè)務(wù)層開(kāi)始干活根據(jù)用戶(hù)ID查詢(xún)用戶(hù)狀態(tài)如果被禁用直接拋異常遍歷商品列表逐一從數(shù)據(jù)層查詢(xún)庫(kù)存用數(shù)據(jù)庫(kù)行鎖或樂(lè)觀鎖保證一致性逐個(gè)判斷庫(kù)存是否充足不足則直接中斷并返回提示計(jì)算商品總價(jià)、優(yōu)惠金額、應(yīng)付金額生成訂單號(hào)組裝訂單主表和明細(xì)表對(duì)象調(diào)用數(shù)據(jù)層插入訂單再扣減庫(kù)存記錄一條操作日志事務(wù)就掛在業(yè)務(wù)層這個(gè)方法的Transactional上。也就是說(shuō)從第一步到最后一步任何異常都會(huì)導(dǎo)致前面所有數(shù)據(jù)操作回滾。這一步是三層架構(gòu)里最簡(jiǎn)單的部分但也是最關(guān)鍵的部分事務(wù)邊界只在業(yè)務(wù)層表現(xiàn)層不開(kāi)啟事務(wù)數(shù)據(jù)層不自己提交事務(wù)。最后把訂單號(hào)、應(yīng)付金額和狀態(tài)封裝成VO返回給ControllerController包裝成標(biāo)準(zhǔn)的JSON響應(yīng)。整個(gè)流程下來(lái)每一層都只干自己的事Controller沒(méi)碰庫(kù)存Service沒(méi)拼SQLRepository沒(méi)寫(xiě)任何if/else。3.3 各層之間傳什么DTO/VO/BO怎么區(qū)分這是T3 Code實(shí)踐中最讓人糾結(jié)的細(xì)節(jié)沒(méi)有之一。我見(jiàn)過(guò)一個(gè)項(xiàng)目里DTO、VO、DO、BO四處亂飛同樣的字段在四個(gè)類(lèi)里各寫(xiě)一遍還經(jīng)常漏字段。我的做法是不同層之間傳不同類(lèi)型的對(duì)象但不要讓這個(gè)規(guī)則變成負(fù)擔(dān)。我常用的約定是這樣的表現(xiàn)層接收前端參數(shù)用DTO比如CreateOrderRequest它代表“外界想讓我做什么”表現(xiàn)層返回給前端的數(shù)據(jù)用VO比如OrderVO它代表“我做完之后你應(yīng)該看到什么”業(yè)務(wù)層內(nèi)部流轉(zhuǎn)的數(shù)據(jù)用BO比如OrderBO它代表“業(yè)務(wù)視角下的訂單全貌”數(shù)據(jù)層操作數(shù)據(jù)庫(kù)用實(shí)體類(lèi)比如OrderDO或Query對(duì)象層與層之間的轉(zhuǎn)換放在哪里我推薦放在適配器里而不是業(yè)務(wù)方法內(nèi)部。比如業(yè)務(wù)層的createOrder接收DTO還是BO我的習(xí)慣是接收DTO因?yàn)镃ontroller直接傳入省一層轉(zhuǎn)換內(nèi)部如果復(fù)雜再轉(zhuǎn)成BO。Repository接收BO還是DO我習(xí)慣是Repository自己把BO拆分成DO或參數(shù)對(duì)象不要讓業(yè)務(wù)層去組裝查詢(xún)參數(shù)。很多爭(zhēng)議其實(shí)都是“對(duì)象怎么命名”的表面問(wèn)題本質(zhì)問(wèn)題是邊界感。只要每個(gè)對(duì)象都有清晰的用途和轉(zhuǎn)換時(shí)機(jī)叫什么都行。但一旦你發(fā)現(xiàn)一個(gè)對(duì)象同時(shí)被前端、業(yè)務(wù)、數(shù)據(jù)三層使用那就是危險(xiǎn)的信號(hào)了。3.4 代碼示例一張訂單業(yè)務(wù)核心鏈路這里我給出一個(gè)簡(jiǎn)化版的Service方法骨架不是完整代碼但足夠展示業(yè)務(wù)層的編排感。以Java為例Transactional(rollbackFor Exception.class) public CreateOrderResponse createOrder(CreateOrderRequest request) { // 1. 查詢(xún)用戶(hù)信息 UserDO user userRepository.findById(request.getUserId()); if (user null || user.getStatus() UserStatus.DISABLED) { throw new BizException(用戶(hù)不存在或已被禁用); } // 2. 查詢(xún)商品庫(kù)存并做扣減此處用樂(lè)觀鎖或行鎖保證并發(fā)安全 ListItemQuery items request.getItems(); ListOrderItemBO orderItems new ArrayList(); BigDecimal totalAmount BigDecimal.ZERO; for (ItemQuery itemQuery : items) { ProductStockDO stock productRepository.findStockForUpdate( itemQuery.getSkuId()); if (stock.getAvailable() itemQuery.getQuantity()) { throw new BizException(商品庫(kù)存不足: itemQuery.getSkuId()); } productRepository.deductStock(itemQuery.getSkuId(), itemQuery.getQuantity()); OrderItemBO orderItem new OrderItemBO(); orderItem.setSkuId(itemQuery.getSkuId()); orderItem.setQuantity(itemQuery.getQuantity()); orderItem.setPrice(stock.getPrice()); orderItems.add(orderItem); totalAmount totalAmount.add(stock.getPrice() .multiply(BigDecimal.valueOf(itemQuery.getQuantity()))); } // 3. 計(jì)算優(yōu)惠并生成訂單 BigDecimal discount calculateDiscount(user, totalAmount); BigDecimal payableAmount totalAmount.subtract(discount); String orderNo generateOrderNo(); OrderDO order new OrderDO(); order.setOrderNo(orderNo); order.setUserId(user.getId()); order.setTotalAmount(totalAmount); order.setPayableAmount(payableAmount); order.setStatus(OrderStatus.CREATED); orderRepository.insert(order); orderItemRepository.batchInsert(order.getId(), orderItems); // 4. 記錄日志并返回 operationLogRepository.log(user.getId(), createOrder, orderNo); CreateOrderResponse response new CreateOrderResponse(); response.setOrderNo(orderNo); response.setPayableAmount(payableAmount); return response; }注意看這個(gè)結(jié)構(gòu)每一塊都和職責(zé)一一對(duì)應(yīng)沒(méi)有Controller的影子也沒(méi)有SQL拼接。這個(gè)方法的每一步你都可以單獨(dú)測(cè)試也方便在中間加日志和監(jiān)控。實(shí)際項(xiàng)目里還會(huì)有價(jià)格計(jì)算服務(wù)、優(yōu)惠策略服務(wù)但編排的核心思想就是這樣。4. 我踩過(guò)的坑和排查問(wèn)題的幾條野路子4.1 最常見(jiàn)的坑業(yè)務(wù)邏輯往Controller里塞我見(jiàn)過(guò)一個(gè)真實(shí)案例。團(tuán)隊(duì)里有個(gè)同事為了“快速上線(xiàn)”把所有校驗(yàn)都寫(xiě)在Controller里Service里只是一個(gè)空殼方法直接調(diào)用Repository。剛開(kāi)始確實(shí)快因?yàn)樯倭藚?shù)傳遞和對(duì)象轉(zhuǎn)換。但后來(lái)需求變了同樣的下單接口App端要加一個(gè)“新人立減”活動(dòng)Web端要加一個(gè)“企業(yè)采購(gòu)”校驗(yàn)。由于業(yè)務(wù)邏輯都在Controller里兩個(gè)入口只能各寫(xiě)各的同一個(gè)下單規(guī)則出現(xiàn)了兩套實(shí)現(xiàn)。再后來(lái)邏輯對(duì)不上了前端A告訴用戶(hù)“可以下單”前端B卻報(bào)“庫(kù)存不足”搞得產(chǎn)品經(jīng)理以為系統(tǒng)有bug。處理辦法只有一個(gè)把Controller里的業(yè)務(wù)代碼全部搬到ServiceController瘦身成真正的“翻譯官”。搬的過(guò)程不算難但要有紀(jì)律——以后但凡有人想在Controller里加業(yè)務(wù)邏輯Code Review就要打回去重寫(xiě)。4.2 事務(wù)到底該放在哪一層這又是一個(gè)高頻踩坑點(diǎn)。很多人寫(xiě)了一個(gè)Service方法里面調(diào)用了兩個(gè)Repository方法但忘記加Transactional結(jié)果第一個(gè)插入成功、第二個(gè)插入失敗數(shù)據(jù)庫(kù)里留下了半個(gè)訂單。更隱蔽的是有人在Controller上加了Transactional雖然也能回滾但Controller變成事務(wù)入口點(diǎn)之后日志、監(jiān)控、異常處理全都亂了套而且Controller如果有多個(gè)方法一不小心就會(huì)把所有接口都包進(jìn)事務(wù)性能直接崩。正確理解是事務(wù)是業(yè)務(wù)層的屬性因?yàn)橹挥袠I(yè)務(wù)層才知道哪些操作是一個(gè)“完整業(yè)務(wù)動(dòng)作”。數(shù)據(jù)層的每個(gè)原子操作默認(rèn)自動(dòng)提交表現(xiàn)層完全不感知事務(wù)。當(dāng)你使用Spring的聲明式事務(wù)時(shí)只要在業(yè)務(wù)方法上標(biāo)注TransactionalSpring會(huì)幫你把連接綁定到線(xiàn)程上數(shù)據(jù)層多個(gè)操作共用同一個(gè)事務(wù)。提示Transactional默認(rèn)只回滾運(yùn)行時(shí)異常如果是checked exception要顯式指定rollbackFor Exception.class否則你會(huì)看到數(shù)據(jù)半提交的幽靈問(wèn)題。這是團(tuán)隊(duì)新人最容易掉進(jìn)去的坑之一。4.3 排查“三層代碼不好調(diào)”的幾個(gè)實(shí)用技巧很多人說(shuō)分層之后代碼難調(diào)——一個(gè)請(qǐng)求要跨越三個(gè)類(lèi)打日志都費(fèi)勁。我自己的排查習(xí)慣是這樣的第一在業(yè)務(wù)層的每個(gè)關(guān)鍵編排節(jié)點(diǎn)打日志包括入?yún)?、中間計(jì)算結(jié)果、出參。這比在Controller和Repository里都打日志更有效因?yàn)闃I(yè)務(wù)層才是整個(gè)流程的決策中心。第二把“請(qǐng)求唯一ID”貫穿三層從Controller入口生成一個(gè)traceId打印日志時(shí)帶上它這樣一次請(qǐng)求的所有日志都能串起來(lái)。第三遇到數(shù)據(jù)一致性問(wèn)題時(shí)優(yōu)先看事務(wù)邊界是否掛對(duì)了方法而不是盯著SQL看。我還有一個(gè)野路子先在Repository里做一次SQL直查確認(rèn)數(shù)據(jù)對(duì)不對(duì)再反推業(yè)務(wù)層邏輯是否出錯(cuò)。這個(gè)方法聽(tīng)起來(lái)簡(jiǎn)單但能快速區(qū)分“數(shù)據(jù)本身有問(wèn)題”和“業(yè)務(wù)規(guī)則算錯(cuò)了”省去大量翻日志的時(shí)間。4.4 一張速查表三層代碼最常見(jiàn)問(wèn)題清單問(wèn)題現(xiàn)象可能原因排查方向Repository里出現(xiàn)if/else或業(yè)務(wù)判斷數(shù)據(jù)層被業(yè)務(wù)污染把判斷上移到業(yè)務(wù)層Controller里直接操作多個(gè)Service編排邏輯散落在表現(xiàn)層在Service里新增編排方法改了字段后前端報(bào)錯(cuò)或數(shù)據(jù)錯(cuò)亂多層共用同一個(gè)實(shí)體對(duì)象引入VO/DTO/BO并做轉(zhuǎn)換事務(wù)不生效部分寫(xiě)了部分沒(méi)寫(xiě)事務(wù)邊界放錯(cuò)位置或異常類(lèi)型未覆蓋檢查T(mén)ransactional位置和rollbackFor一個(gè)接口改動(dòng)導(dǎo)致另一個(gè)入口數(shù)據(jù)異常多入口各寫(xiě)一套業(yè)務(wù)規(guī)則統(tǒng)一收斂到業(yè)務(wù)層單元測(cè)試難寫(xiě)Mock太多Service依賴(lài)了具體實(shí)現(xiàn)類(lèi)或SQL面向接口編程依賴(lài)抽象5. 什么情況下T3 Code不再適用聊了半天三層架構(gòu)的好處我也想聊聊它不適用的場(chǎng)景。不是所有項(xiàng)目都需要嚴(yán)格的三層代碼很多輕量級(jí)項(xiàng)目用三層反而是負(fù)擔(dān)。第一種情況是純CRUD管理后臺(tái)。如果只是簡(jiǎn)單的表格增刪改查沒(méi)有復(fù)雜的業(yè)務(wù)規(guī)則和流程編排硬拆三層會(huì)多出大量無(wú)意義的轉(zhuǎn)換代碼。這種項(xiàng)目用Controller直接操作Repository甚至直接用MyBatis-Plus的Service接口反而更省事。第二種情況是腳本任務(wù)和定時(shí)任務(wù)它們本身沒(méi)有表現(xiàn)層直接從任務(wù)方法進(jìn)入業(yè)務(wù)層即可沒(méi)必要為了“三層對(duì)稱(chēng)”硬造一個(gè)Controller。第三種情況是簡(jiǎn)單的讀多寫(xiě)少查詢(xún)服務(wù)直接走Repository查數(shù)據(jù)返回即可套三層只會(huì)增加延遲和代碼量。我個(gè)人的判斷標(biāo)準(zhǔn)是如果一段業(yè)務(wù)邏輯未來(lái)會(huì)被多個(gè)入口復(fù)用或者有超過(guò)三步的流程編排那它就該有一個(gè)獨(dú)立的業(yè)務(wù)層方法。如果只是一次性的數(shù)據(jù)讀取就不要為了分層而分層。T3 Code是一種手段不是一個(gè)必須遵從的宗教教條。工具鏈上我建議配合單元測(cè)試來(lái)做分層守護(hù)每層都能獨(dú)立測(cè)試業(yè)務(wù)層用Mock數(shù)據(jù)層來(lái)測(cè)試規(guī)則數(shù)據(jù)層用真實(shí)數(shù)據(jù)庫(kù)做集成測(cè)試。分層不是為了讓代碼看起來(lái)高級(jí)而是為了降低維護(hù)成本。你能在不需要啟動(dòng)Web容器的情況下把一個(gè)業(yè)務(wù)異常用例寫(xiě)出來(lái)并跑通那分層就真正有了價(jià)值。這也是我判斷“T3 Code落地得好不好”的最直接標(biāo)準(zhǔn)。