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

Domain領域業(yè)務層與ADM模式解說

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

何為Api-Domain-Model模式？

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

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

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

簡單來說，

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

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

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

專注領域的Domain業(yè)務層

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

ADM職責劃分與調(diào)用關系

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

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

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

Api接口服務層應該做：

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

• 應該：調(diào)度領域業(yè)務層

  Api接口服務層不應該做：

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

• 不應該：將多個接口合并在一起

  Domain領域業(yè)務層應該做：

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

Domain領域業(yè)務層不應該做：

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

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

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

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

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

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

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

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

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

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

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

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

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

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