1.6 PhalApi 2.x Domain領(lǐng)域?qū)雍虯DM模式

Domain領(lǐng)域業(yè)務(wù)層與ADM模式解說

PhalApi使用的是ADM分層模式，Domain是連接Api層與Model層的橋梁。

何為Api-Domain-Model模式？

在傳統(tǒng)Web框架中，慣用MVC模式?？梢哉f，MVC模式是使用最為廣泛的模式，但同時(shí)也可能是誤解最多的模式。然而，接口服務(wù)這一領(lǐng)域，與傳統(tǒng)的Web應(yīng)用所面向的領(lǐng)域和需要解決的問題不同，最為明顯的是接口服務(wù)領(lǐng)域中沒有View視圖。如果把MVC模式生搬硬套到接口服務(wù)領(lǐng)域，不但會(huì)產(chǎn)生更多對(duì)MVC模式的誤解，還不利于實(shí)際接口服務(wù)項(xiàng)目的開發(fā)和交付。

仔細(xì)深入地再思考一番，接口服務(wù)除了需要處理輸入和輸出，以及從持久化的存儲(chǔ)媒介中提取、保存、刪除、更新數(shù)據(jù)外，還有一個(gè)相當(dāng)重要且不容忽視的任務(wù)——處理特定領(lǐng)域的業(yè)務(wù)規(guī)則。而這些規(guī)則的處理幾乎都是邏輯層面上對(duì)數(shù)據(jù)信息的加工、轉(zhuǎn)換、處理等操作，以滿足特定場(chǎng)景的業(yè)務(wù)需求。對(duì)于這些看不見，摸不著，聽不到的領(lǐng)域規(guī)則處理，卻具備著交付有價(jià)值的業(yè)務(wù)功能的使命，與此同時(shí)也是最為容易出現(xiàn)問題，產(chǎn)生線上故障，引發(fā)損失的危險(xiǎn)區(qū)。所以，在接口服務(wù)過程中，我們應(yīng)該把這些領(lǐng)域業(yè)務(wù)規(guī)則的處理，把這些受市場(chǎng)變化而頻繁變動(dòng)的熱區(qū)，單獨(dú)封裝成一層，并配套完備的自動(dòng)化測(cè)試體系，保證核心業(yè)務(wù)的穩(wěn)定性。

基于以上考慮，在MVC模式的基礎(chǔ)上，我們?nèi)サ袅薞iew視圖層，添加了Domain領(lǐng)域業(yè)務(wù)層。從而涌現(xiàn)了Api-Domain-Model模式，簡(jiǎn)稱ADM模式。

簡(jiǎn)單來說，

• Api層 稱為接口服務(wù)層，負(fù)責(zé)對(duì)客戶端的請(qǐng)求進(jìn)行響應(yīng)，處理接收客戶端傳遞的參數(shù)，進(jìn)行高層決策并對(duì)領(lǐng)域業(yè)務(wù)層進(jìn)行調(diào)度，最后將處理結(jié)果返回給客戶端。

• Domain層 稱為領(lǐng)域業(yè)務(wù)層，負(fù)責(zé)對(duì)領(lǐng)域業(yè)務(wù)的規(guī)則處理，重點(diǎn)關(guān)注對(duì)數(shù)據(jù)的邏輯處理、轉(zhuǎn)換和加工，封裝并體現(xiàn)特定領(lǐng)域業(yè)務(wù)的規(guī)則。

• Model層 稱為數(shù)據(jù)模型層，負(fù)責(zé)技術(shù)層面上對(duì)數(shù)據(jù)信息的提取、存儲(chǔ)、更新和刪除等操作，數(shù)據(jù)可來自內(nèi)存，也可以來自持久化存儲(chǔ)媒介，甚至可以是來自外部第三方系統(tǒng)。

專注領(lǐng)域的Domain業(yè)務(wù)層

Domain領(lǐng)域業(yè)務(wù)層，主要關(guān)注的是領(lǐng)域業(yè)務(wù)規(guī)則的處理。在這一層，不應(yīng)過多關(guān)注外界客戶端接口調(diào)用的簽名驗(yàn)證、參數(shù)獲取、安全性等問題，也不應(yīng)過多考慮數(shù)據(jù)從何而來、存放于何處，而是著重關(guān)注對(duì)領(lǐng)域業(yè)務(wù)數(shù)據(jù)的處理。

ADM職責(zé)劃分與調(diào)用關(guān)系

傳統(tǒng)的接口開發(fā)，由于沒有很好的分層結(jié)構(gòu)，而且熱衷于在一個(gè)文件里面完成絕大部分事情，最終導(dǎo)致了臃腫漫長(zhǎng)的代碼，也就是通常所說的意大利面條式的代碼。

在PhalApi中，我們針對(duì)接口領(lǐng)域開發(fā)，提供了新的分層思想：Api-Domain-Model模式。即便這樣，如果項(xiàng)目在實(shí)際開發(fā)中，仍然使用原來的做法，縱使再好的接口開發(fā)框架，也還是會(huì)退化到原來的局面。

為了能讓大家更為明確Api接口層的職責(zé)所在，我們建議：

Api接口服務(wù)層應(yīng)該做：

• 應(yīng)該：對(duì)用戶登錄態(tài)進(jìn)行必要的檢測(cè)
• 應(yīng)該：控制業(yè)務(wù)場(chǎng)景的主流程，創(chuàng)建領(lǐng)域業(yè)務(wù)實(shí)例，并進(jìn)行調(diào)用
• 應(yīng)該：進(jìn)行必要的日記紀(jì)錄
• 應(yīng)該：返回接口結(jié)果

• 應(yīng)該：調(diào)度領(lǐng)域業(yè)務(wù)層

  Api接口服務(wù)層不應(yīng)該做：

• 不應(yīng)該：進(jìn)行業(yè)務(wù)規(guī)則的處理或者計(jì)算
• 不應(yīng)該：關(guān)心數(shù)據(jù)是否使用緩存，或進(jìn)行緩存相關(guān)的直接操作
• 不應(yīng)該：直接操作數(shù)據(jù)庫(kù)

• 不應(yīng)該：將多個(gè)接口合并在一起

  Domain領(lǐng)域業(yè)務(wù)層應(yīng)該做：

• 應(yīng)該：體現(xiàn)特定領(lǐng)域的業(yè)務(wù)規(guī)則
• 應(yīng)該：對(duì)數(shù)據(jù)進(jìn)行邏輯上的處理
• 應(yīng)該：調(diào)度數(shù)據(jù)模型層或其他領(lǐng)域業(yè)務(wù)層

Domain領(lǐng)域業(yè)務(wù)層不應(yīng)該做：

• 不應(yīng)該：直接實(shí)現(xiàn)數(shù)據(jù)的操作，如添加并實(shí)現(xiàn)緩存機(jī)制

Model數(shù)據(jù)模型層應(yīng)該：

• 應(yīng)該：進(jìn)行數(shù)據(jù)庫(kù)的操作
• 應(yīng)該：實(shí)現(xiàn)緩存機(jī)制

在明確了上面應(yīng)該做的和不應(yīng)該做的，并且也完成了接口的定義，還有驗(yàn)收測(cè)序驅(qū)動(dòng)開發(fā)的場(chǎng)景準(zhǔn)備后，相信這時(shí)，即使是新手也可以編寫出高質(zhì)量的接口代碼。因?yàn)樗麜?huì)受到約束，他知道他需要做什么，主要他按照限定的開發(fā)流程和約定稍加努力即可。

如果真的這樣，相信我們也就慢慢能體會(huì)到精益開發(fā)的樂趣。

至于調(diào)用關(guān)系，整體上講，應(yīng)根據(jù)從Api接口層、Domain領(lǐng)域?qū)釉俚組odel數(shù)據(jù)源層的順序進(jìn)行開發(fā)。

在開發(fā)過程中，需要注意不能越層調(diào)用也不能逆向調(diào)用，即不能Api調(diào)用Model。而應(yīng)該是上層調(diào)用下層，或者同層級(jí)調(diào)用，也就是說，我們應(yīng)該：

• Api層調(diào)用Domain層
• Domain層調(diào)用Domain層
• Domain層調(diào)用Model層

• Model層調(diào)用Model層

  如果用一張圖來表示，則是：

為了更明確調(diào)用的關(guān)系，以下調(diào)用是錯(cuò)誤的：

• 錯(cuò)誤的做法1：Api層直接調(diào)用Model層
• 錯(cuò)誤的做法2: Domain層調(diào)用Api層，也不應(yīng)用將Api層對(duì)象傳遞給Domain層

• 錯(cuò)誤的做法3: Model層調(diào)用Domain層

這樣的約定，便于我們形成統(tǒng)一的開發(fā)規(guī)范，降低學(xué)習(xí)維護(hù)成本。比如需要添加緩存，我們知道應(yīng)該定位到Model層數(shù)據(jù)源進(jìn)行擴(kuò)展；若發(fā)現(xiàn)業(yè)務(wù)規(guī)則處理不當(dāng)，則應(yīng)該進(jìn)入Domain層探其究竟；如果需要對(duì)接口的參數(shù)進(jìn)行調(diào)整，即使是新手也知道應(yīng)該找到對(duì)應(yīng)的Api文件進(jìn)行改動(dòng)。