關于adm思想主要是指在api開發中使用api,domain和model三層結構,phalgo從phalapi中學習并且推崇這種設計模式,這種模式的好處在于分工明确,業務複用,資料複用可以減少複雜業務重複的代碼量,很多架構關心性能，而不關心人文；很多項目關心技術，而不關注業務。adm設計就是從業務的角度出發建立的開發規範.
api層可以了解為是請求開始結束以及組合業務的地方,主要負責以下幾件事情:
擷取請求參數并且驗證請求參數的有效性
對domain領域層的實作進行拼接來組成整個接口的業務
對于傳回結果進行處理
我們可以看一個擷取使用者詳情接口的例子:
(1)api接口層應該做：
應該：對使用者登入态進行必要的檢測
應該：控制業務場景的主流程，建立領域業務執行個體，并進行調用
應該：進行必要的日志紀錄
應該：傳回接口結果
(2)api接口層不應該做：
不應該：進行業務規則的處理或者計算
不應該：關心資料是否使用緩存，或進行緩存相關的直接操作
不應該：直接操作資料庫
不應該：将多個接口合并在一起
domain可以稱之為領域層,是adm（api-domain-model）分層中的橋梁，主要負責處理業務規則。domain層存在的目錄是為了把複雜業務拆分成一個一個小子產品然後組織起來實作複雜的業務,進而達到代碼複用,拆分複雜業務的作用.
場景:我們在傳統mvc開發的時候,使用控制器來處理業務,我們可能會寫很多的重複代碼來驗證使用者送出的資訊是否ok,比如完善資訊的時候驗證郵箱,在修改使用者資訊的時候也要驗證修改的郵箱,在管理的時候去編輯一個使用者的時候也可能在去驗證郵箱,這個時候我們的驗證邏輯代碼已經重複寫在了3個地方,如果有一個需求加入了電話号碼,那麼你需要在3個地方加上對電話号碼的驗證邏輯
場景一并不難以遇到,而且在複雜的業務情況下重複使用的業務邏輯會更多,如果我們使用了domain來處理使用者修改前的驗證那麼我們隻需要修改這個驗證邏輯加上對電話号碼的驗證,那麼所有需要驗證使用者資訊的地方就會全部生效,而不用去做重複的工作并且避免遺漏的風險
下面是我們擷取user詳情的domain層的實作,它不僅僅隻是可以用在擷取使用者詳情也可以用來驗證使用者id是否有效,增加代碼複用性減少修改代價
一個函數如果超過了一屏那将會影響到閱讀者的了解,使用領域層拆分笨重的業務可以很好的解決這個問題
model層想必不用說了,就是和資料庫通訊擷取資料,model層是單純的不帶任何業務隻是簡單的擷取資料庫資料,我們看一段model層代碼:
注意:model層隻應該擷取資料然後結束關于沒有擷取到資料,擷取出錯等情況抛出到domain層進行處理,這樣可以增加靈活性,比如通過使用者名是否重複和通過使用者名稱擷取id,一個傳回存在才算異常,一個傳回不存在才算異常,具體更具業務不同展現也不同,是以model層處理并不合适
整體上講根據從api接口層、domain領域層再到model資料源層的順序進行開發。
在開發過程中，需要注意不能越層調用也不能逆向調用，即不能api調用model。而應該是上層調用下層，或者同層級調用，也就是說，我們應該：
api層調用domain層
domain層調用domain層
domain層調用model層
model層調用model層
為了更明确調用的關系，以下調用是 錯誤 的：
錯誤的做法1：api層直接調用model層
錯誤的做法2: domain層調用api層，也不應用将api層對象傳遞給domain層
錯誤的做法3: model層調用domain層
這樣的約定，便于我們形成統一的開發規範，降低學習維護成本。
比如需要添加緩存，我們知道應該定位到model層資料源進行擴充；若發現業務規則處理不當，則應該進入domain層探其究竟；如果需要對接口的參數進行調整，即使是新手也知道應該找到對應的api檔案進行改動。