1、 基于領(lǐng)域分析設(shè)計(jì)的架構(gòu)規(guī)范充血模型之實(shí)體目 錄 TOC o 1-3 h z u HYPERLINK l _Toc26013528 1.讀寫隔離后的世界 PAGEREF _Toc26013528 h 3 HYPERLINK l _Toc26013529 2.業(yè)務(wù)靈魂-狀態(tài)圖 PAGEREF _Toc26013529 h 4 HYPERLINK l _Toc26013530 3.貧血模型的世界 PAGEREF _Toc26013530 h 6 HYPERLINK l _Toc26013531 4.實(shí)體Entity的世界 PAGEREF _Toc26013531 h 7讀寫隔離后的世界基于上面提到

2、的讀寫隔離的思想，那么我們可以很清楚地看到上面這種情況可以看到：查詢業(yè)務(wù)，從入口層（如Controller），調(diào)用Finder，而Finder調(diào)用Repository（具體實(shí)現(xiàn)如Hiberante，Mybatis等等均可），這一條線下來(lái)，我們?nèi)徊挥每紤]這個(gè)系統(tǒng)的增刪改就是如何做的，就像他們完全處于不同的空間一樣，互不干涉，互不影響，甚至，永遠(yuǎn)互不相見。某種程度上來(lái)說(shuō)，這種這種架構(gòu)追求的效果，一種美感。所以，接下來(lái)，我們關(guān)注的，就是增刪改這一部分了，也就是命令操作是開始要扎扎實(shí)實(shí)地來(lái)對(duì)這個(gè)系統(tǒng)進(jìn)行修改了首先讓我們把視野抬高一些，從整個(gè)項(xiàng)目產(chǎn)品的上空來(lái)看看業(yè)務(wù)靈魂-狀態(tài)圖除開少數(shù)非常扁平的純技術(shù)

3、服務(wù)項(xiàng)目（比如AI識(shí)別，文本分析等等），其他絕大部分企業(yè)項(xiàng)目都有其核心的商業(yè)邏輯，而這些邏輯，往往也會(huì)以核心的領(lǐng)域概念來(lái)提現(xiàn)，從簡(jiǎn)單粗暴一點(diǎn)角度映射到設(shè)計(jì)開發(fā)中，那就是類class電商系統(tǒng)，核心領(lǐng)域至少有【商品】，【訂單】，【用戶】，【物流】等；SNS社交平臺(tái)，至少有【用戶】，【博文/帖子】，【私信】，【通知】等；進(jìn)銷存系統(tǒng)，至少有【賬戶】，【角色/權(quán)限】，【商品】,【客戶/供應(yīng)商】等；在線教育平臺(tái)，至少有【用戶】，【課程】，【訂單】等；而這其中，也有主次，大家可以回頭看看自己所開發(fā)過(guò)的項(xiàng)目。但凡是有狀態(tài)字段的類，很大可能都是整個(gè)項(xiàng)目的核心領(lǐng)域之一。其實(shí)很好理解，因?yàn)樗辛鞒蹋驗(yàn)樗枰桓黝?/p>

4、操作來(lái)變更它的狀態(tài)，所以，他很可能貫穿了這個(gè)項(xiàng)目中某一個(gè)關(guān)鍵商業(yè)邏輯，比如電商系統(tǒng)中,【訂單】肯定有狀態(tài)，從待支付-已支付-派送中-已收貨，甚至還有已取消，退款中，退款失敗，退款成功，腦補(bǔ)一下，就知道會(huì)生成多少?gòu)?fù)雜的業(yè)務(wù)流程了【用戶】一般來(lái)說(shuō)也會(huì)有狀態(tài)，比如正常，凍結(jié)，但是可以想到，如果某個(gè)系統(tǒng)沒有這方面權(quán)限與安全的要求，【用戶】也可能就沒有狀態(tài)了，那么自然也不會(huì)有對(duì)應(yīng)的操作對(duì)其進(jìn)行修改，可能只會(huì)有創(chuàng)建所以，如果在這些系統(tǒng)的早期設(shè)計(jì)階段，要我選擇一個(gè)最重要的UML圖，我會(huì)選擇狀態(tài)圖，以下就是整個(gè)系統(tǒng)中最核心的訂單狀態(tài)圖可以看到，把握一個(gè)核心領(lǐng)域的狀態(tài)變更，自然而然就能歸納出來(lái)很大一部分系統(tǒng)的功

5、能需求。我們?cè)谶@里看到，這些所有箭頭所觸發(fā)的動(dòng)作，其實(shí)都是命令，也其實(shí)都是會(huì)落地到各個(gè)相關(guān)領(lǐng)域的增刪改上。當(dāng)然這里還是一個(gè)粗粒度的表示，無(wú)法單單依據(jù)這個(gè)就馬上落地開發(fā)，因?yàn)榧词姑恳粋€(gè)箭頭所代表的功能都可以寫出一個(gè)完整甚至很復(fù)雜的用例。但至少這是一個(gè)非常清晰的引導(dǎo)。貧血模型的世界我們目前所用的Spring體系，幾乎都是貧血模型，也就是說(shuō)，真正的實(shí)體類里，都只有各個(gè)屬性的Get與Set方法。而假如我們要進(jìn)行一個(gè)操作，訂單取消，那么最常見的做法是什么？/一個(gè)大而全的訂單服務(wù)類public class OrderService public void cancelOrder(Long orderId)

6、 Order order = orderRepository.getById(orderId); order.setStatus(OrderStatus.CANCELLED); /省略，其他屬性的操作. /然后在上層（如Controller層）中這么調(diào)用orderService.cancelOrder(10086);這是目前行業(yè)中非常流行的做法，也是Spring的IOC機(jī)制天然形成的做法盡可能的無(wú)狀態(tài)化。這種做法，在業(yè)務(wù)迭代時(shí)對(duì)代碼的變動(dòng)評(píng)判標(biāo)準(zhǔn)相對(duì)簡(jiǎn)單，都往Service里放就行了，然后實(shí)體對(duì)象只需要GetSet即可，簡(jiǎn)單粗暴，非常容易上手，也正是這種特性，讓這種編碼風(fēng)格廣為流傳。以上這些話

7、沒有任何貶義，因?yàn)槿魏问虑椋嬖诩春侠?，我所?jīng)歷的公司項(xiàng)目，幾乎都是這樣做的，大家合作起來(lái)沒多大問(wèn)題，業(yè)務(wù)也都還跑得不錯(cuò)。那為什么我還想去做一些改變呢？實(shí)體Entity的世界因?yàn)槲矣X得我們需要再重新審視一下實(shí)體Entity實(shí)體為什么要有主鍵？因?yàn)闆]有主鍵，那我們?cè)趺粗罆r(shí)要查詢/修改哪條數(shù)據(jù)呢？這個(gè)回答沒有問(wèn)題，只是這句話里其實(shí)還蘊(yùn)藏更深的含義這個(gè)實(shí)體是一個(gè)真實(shí)存在的東西（對(duì)，哪怕它看不見摸不著，但也是存在的），而且會(huì)以一種形態(tài)被“存儲(chǔ)/持久化”在一個(gè)存儲(chǔ)介質(zhì)里，比如說(shuō)數(shù)據(jù)庫(kù);當(dāng)我們需要對(duì)某個(gè)實(shí)體進(jìn)行操作時(shí)，我們需要通過(guò)一種手段將它“加載/讀取/獲得”出來(lái)，就像你取快遞時(shí)，快遞員根據(jù)你提供的編

8、號(hào)，從包裹里把那個(gè)東西取出來(lái)，完全一樣;取出來(lái)了怎么辦？那自然就是要對(duì)它進(jìn)行操作了。沒錯(cuò)，這個(gè)操作，就是對(duì)我們找出來(lái)的實(shí)體進(jìn)行操作，而不是別的東西。所以，從“拿取”，到“操作”，這兩步，一切順理成章，行云流水，所以，以領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的做法，或者說(shuō)，充血模型的做法，會(huì)是這樣：/應(yīng)用層入口類，這里以Controller為例public class OrderController PostMapping(/cancel) Transactional public ActionResponse cancelOrder(RequestBody CancelOrderRequest request) /拿取

9、：根據(jù)標(biāo)識(shí)符定位到我們要操作的實(shí)體 Order order = orderRepository.getById(request.getOrderId(); /操作：對(duì)，沒錯(cuò)，說(shuō)的就是你 order，就是對(duì)你，進(jìn)行操作，不是別人！ order.cancel(); /返回結(jié)果 return ActionResponse.ok(); /真正的業(yè)務(wù)邏輯，就是在Order實(shí)體里Entitypublic class Order private OrderStatus status; private String customerName; /. public void cancel() /變更狀態(tài) sta

10、tus = OrderStatus.CANCELLED; /一些其他屬性變動(dòng)，略 好，依舊有不少值得探討的地方：我們這里直接在Controller中就開啟了Transactional，可能看起來(lái)有點(diǎn)反常規(guī)，但我個(gè)人覺得沒什么問(wèn)題，除了有點(diǎn)不習(xí)慣，仔細(xì)想想，本身都只不過(guò)是Spring的一種組件而已所以如果你用的諸如Hibernate之類的JDBC框架，可以無(wú)需再進(jìn)行多余的類似save操作，這也更好的提現(xiàn)了領(lǐng)域設(shè)計(jì)的思想，因?yàn)檫@時(shí)，這個(gè)order就是一個(gè)實(shí)實(shí)在在被我們找出來(lái)的實(shí)體，對(duì)它的改動(dòng)，自動(dòng)映射到底層持久化，很自然，也必然。最更容易引發(fā)槽點(diǎn)的地方，就是order.cancel()，也就是充血

11、模型的精髓，將行為定位到一個(gè)實(shí)體類上，而不是不加思考地直接扔進(jìn)OrderService里。業(yè)界一直有一種非?！懊烂睢钡卣f(shuō)法，曾經(jīng)我一度非常向往，就是“讓代碼成詩(shī)”。換句話說(shuō)，就是既然追求可讀性，那么我們要盡可能的讓代碼天然具有一種“主謂賓”的感覺，就拿上面“取消訂單”做比方，我們是否會(huì)覺得：訂單好端端的在那里放著，它自己又不能對(duì)自己做什么，自然應(yīng)該“別人”對(duì)他進(jìn)行了操作：OrderService.cancel(orderId); 某某某 取消了 這個(gè)訂單Perfect! 這樣讀起來(lái)，才非常通順，可讀性才更好！我曾經(jīng)也是這種風(fēng)格死忠，而Spring廣為流傳的無(wú)狀態(tài)架構(gòu)模式也將這種風(fēng)格發(fā)揚(yáng)光大。只

12、是我現(xiàn)在，在經(jīng)歷了越來(lái)越多復(fù)雜業(yè)務(wù)，長(zhǎng)事務(wù)的開發(fā)需求后，越來(lái)越覺得，這個(gè)還有有些硬傷如果一定要讀得通暢，更應(yīng)該是someOperator.cancel(orderId)即某個(gè)操作人取消了訂單，而不是OrderService，誰(shuí)都知道OrderService就是一個(gè)無(wú)狀態(tài)的代碼大集合，一個(gè)冰冷的代碼而已。但顯然someOperator.cancel(orderId)這種做法也是更加不可能實(shí)現(xiàn)的，原因就不用過(guò)多解釋了。order.cancel()，只有2個(gè)部分，操作目標(biāo)是誰(shuí).做了什么事情，清晰明了，言簡(jiǎn)意賅。我相信絕大多數(shù)人的閱讀習(xí)慣也都是從左往右，那么視線第一下掃到的目標(biāo)一定是最左邊的執(zhí)行對(duì)象，也