戲說領域驅動設計（廿一）——領域服務

　　物體物件和值物件都寫完了，本想開始寫資源倉庫順便把作業單元再搞搞，不過有一點麻煩的是我不太想把作業單元作為單獨的一章來寫，一是這東西網上相關的內容太多；二是有的時候使用Spirng的事務就解決了，沒覺得有多大作用，不過先不糾結這些，還是按本章的主題寫領域服務吧，這好講，誰不喜歡簡單的東西，

一、為啥引入領域服務

　　要說原因吧，其實也挺簡單的，在開發程序中你會發現有些方法不知道放哪個物件身上合適，比如說經典的轉賬業務：放客戶物件上不合適，客戶物件中沒有余額的概念；放賬戶上面吧，感覺也差了點意思，這里涉及到了兩個物件的變化而且都需要進行存盤，比如您的代碼可能會這樣寫“a.transfer(b)”，一般在開發時最好別在方法中直接修改引數的值，只你自己用或看也許問題不大，別人要使用的時候誰會想到引數也會被方法變更？JDK里那么多方法，雖然沒統計過但我感覺幾乎很少出現方法改引數的情況，還有的時候，一些方法所做的事情不是業務邏輯而是轉換，比如根據引數構建領域物體，這種糙活誰誰都不愿意干，哪個物件都有自己的矜持與驕傲，你讓他干這些活，那是看不起人家，總而言之吧，涉及跨領域物件操作、物件轉換以及沒人愿意干的活時交給領域服務這個老好人就妥了，這家伙是系統中的中間人、和事老，可您不能小瞧人家，領域服務也有自己的體面的，干得活再雜也是BO層中的大佬，DAO、應用服務都得圍著人家轉呢，而且，你別看他不起眼兒，關鍵時間方能顯出英雄本色，要不然你的代碼就是一坨那個……

二、領域服務的責任

　　BO層中有些東西雖然看著不重要，可不能簡單的輕看人家，干得活絕對不含糊，您看上面這個圖，領域服務要干得事兒也不少呢，不過你用的時候可也得注意兩點：一是和應用服務的區分，后面那東西雖然重要可他不處理業務，人家管的是事務、安全、流程控制等，我們領域服務雖然沒有物體風光，那也是處理業務的，二是在領域服務中，你可不能訪問或使用DAO、IoC、Spring甚至是Log，他和這些人都是老死不相往來的，當然了，也有一種編程模式說您可以使用比如Spring的IoC將領域服務注入到應用服務中，其中領域服務的介面在BO層中定義，反正我個人比較反對這么干，與基礎設施耦合不說，你能注入就代表定義和實作是分開的，實作中可以訪問DAO或其它的應用服務，再度造成了反向依賴的問題，我們有一個資源庫這么干就行了，別老是整出太多的四不像來，再說了，資源庫的目的主要就是幫助領域模型和資料模型進行解耦，你將領域服務的定義與實作分開，要和誰解耦？

　　物體、值物件、資源倉庫介面及領域服務是領域模型層的四位公子，而作為BO中的四公子之一，領域服務是最為謙和的，不像物體那么張揚，不像資源倉庫那么粗劣，然而成也蕭何敗也蕭何：你用得多了，領域模型變成了貧血模型；用少了，代碼看著亂七八糟，隨隨便便，不偏不倚才能讓設計出來的東西更加有組織、有原則，所以我們需要重點說說如何使用領域服務，

二、如何使用

　　首先，領域服務一般是不包含屬性的，如果你在設計程序中發現需要在其中增加屬性，那此時你就得開始考慮一下是不是應該把方法和屬性放到某個物體或值物件中更合適，只有后兩者才是包含屬性的物件，那位說了：服務一般是單例的，你不加屬性是為了避免并發，那可以用ThreadLocal行不？肯定不行啊，能稱之為服務的物件就代表其主要是執行某個動作，加屬性不僅違反了服務的使用模式也說明你對領域模型的認識度還不夠，另外，為了少寫點代碼，您用的時候把領域服務建模為單例（不需要使用volatile關鍵字，這東西用多了容易引入總線風暴）更好，不用非得先new再呼叫實體方法，麻煩！

　　第二，如果某個業務需要跨領域模型或者說是跨物體，此時也是使用領域服務的最佳時機，這條約束作為開發規范在團隊中進行要求是有意義的，您還記得我在前面說過開發程序中會涉及到三類服務吧？分別是：應用服務、資料服務和領域服務，這仨東西有一個共同的責任：“流程組織”，前兩者用于組織用例的控制流程和資料的操作流程，而領域服務則用于組織業務流程，他通過協調多個領域物件的互動來完成某個業務，屬于指揮官的角色，比如下列的代碼：在建立新的優惠策略的時候需要約束系統中不能存在優惠條件相同的優惠，相當于將目標優惠與現存優惠做沖突檢測，很明顯，這項業務是跨領域模型的，所以我建立了一個應用服務來完成任務，您再注意一下下面代碼所使用的單例模式，這種方式可以有效的簡化領域服務的使用，

public class DiscountConflictionTestService {

    final public static DiscountConflictionTestService INSTANCE = new DiscountConflictionTestService();

    private DiscountConflictionTestService() {

    }

    /**
     * 優惠條件沖突檢測
     * @param target 目標優惠
     * @param sources 優惠串列
     */
    public List<Discount> testConflictions(Discount target, List<Discount> sources) {
        if (target == null || sources == null) {
            return new ArrayList<Discount>();
        }
        List<Discount> result = this.compareWithExists(target, sources);
        //比較優惠自身是否也有策略沖突
        if (target.hasConflict()) {
            result.add(target);
        }

        Collections.reverse(result);
        return result;
    }
}

　　在繼續之前我們來說一下微服務架構下的領域服務要怎么玩兒，其實都不用說跨服務這個層級的互動，假如某個業務需要兩個或多個包內的物件共同參與時要怎么寫代碼？本質上跨包與跨服務是一樣的處置方式，你都不能直接參考外部包內的領域模型，如果看過前面的文章您應該記得我說過兩個包之間的互動只能通過視圖模型，這個原則其實是強制性的，我們還是以下單為例，具體需求為“下單前要判斷用戶是否未被凍結且已經實名認證”，好多人下意識的做法是這樣的，

@Service
public class OrderService {
    @Resource
    private AccountService accountService;
    
    public void placeOrder(OrderDetail orderDetail, String accountId) {
        AccountVO account = this.accountService.queryById(accountId);
        if (account.getStatus() == AccountStatus.FREEZEN) {
            ……
        }
        if (!account.isAuthenticated()) {
            ……
        }
        Order order = OrderFactoryService.create(orderDetail, account);
        ……
    }    
}

　　這段代碼其實挺不錯，遵循了跨包訪問的規范，只可惜不太符合OOP的要求，面向程序的味道太重了，在我們使用OOP的時候，如果您想確保代碼的純粹那就遵循這樣的規則：應用服務中業務的參與者只能是領域模型，上面的示例中，“AccountVO”是視圖模型，“Order”和“OrderFactoryService”是領域模型，這兩類物件混著玩差了點意思，雖然視圖模型只是參與了驗證，并沒有實作過多的業務，可此處的驗證也是業務規則的重要組成部分，當然你也可以質問我：不是你說的嗎？兩個包之間不能相互訪問領域模型，我已經傳過來了視圖模型，你又說我的編程四不像，找事兒唄？

　　這事兒要怎么說呢，我覺得下面這段解釋還是很重要的，您最好拿個小本本兒記下來，提前宣告一下，我之前寫過的本系列的第十九篇“外驗”中提到過“把驗證抽象成業務規則從應用服務的代碼中剝離出去”，下面這段思想與之并不沖突，請務必注意，既然面向物件編程時應用服務中的業務參與者應該都是領域模型，那么你就應該站在領域模型的立場來設計代碼，在賬戶背景關系中，我們往往會將賬戶建立成物體，所關注的大概是這幾個方面：用戶基本資訊、聯系方式、狀態、級別、是否實名、積分等，大部分電商系統中的賬戶都差不多會關心上述資訊，而到了訂單背景關系中，我們關心的則是這個賬戶在購買商品時所需要的一些資訊比如聯系方式、是否會員以及影響購買的因素資訊比如我們在訂購業務中所要求的“必須實名化”等，在這兩個背景關系中都涉及到了賬戶，技術角度來看，所指向的資訊其實是同一張表，但在業務上的關注點卻完全不一樣，比如您可能不太會在訂購BC中關心用戶年齡吧？

　　基于上述原因，所謂的“賬戶”概念在賬戶BC中這么稱呼是合理的，放到訂購BC中再這么叫就差了點意思，因為我們只關心賬戶的某一部分，所以最好能給這一部分一個新的名字比如“客戶詳情”，客戶詳情是在訂購BC中所建立的一個物體，其作用范圍也僅限于訂購BC里，他的創建方式其實很簡單，通過使用賬戶BC傳過來的視圖模型，根據其中的屬性使用建構式也好或物件工廠也好進行實體化，如果您明白了這段所講，上面的代碼就應該變成如下樣式，

public class CustomerDetail extends EntityModel<Long> {
    private Status status;
    
    public CustomerDetail(AccountVO account) {
        this.status = new Status(account.getStatus());
    }
    
    public boolean canOrder() {
        if (!this.status.canOrder()) {
            return false;
        }
        if (!account.isAuthenticated()) {
            return false;
        }
        return true;
    }
}

@Service
public class OrderService {
    @Resource
    private AccountService accountService;
    
    public void placeOrder(OrderDetail orderDetail, String accountId) {
        CustomerDetail customer = this.constructCustomer(accountId);
　　　　 if (customer.canOrder()) {
　　　　 　　……
　　　　 }        
        Order order = OrderFactory.create(orderDetail, customer);
        ……
    }

    private CustomerDetail constructCustomer(String accountId) {
        AccountVO account = this.accountService.queryById(accountId);
        return new CustomerDetail(account);
    }
}

　　上述的代碼相信對您領悟OOP多少有一點幫助，其實單純的面向程序和面向物件都挺好，是兩種不同的編程模型；兩種混搭其實也不像某些人說的那么不堪，您也知道，由于物件的存在會使得代碼更加內聚，所以即使一部分代碼使用了OOP，總比代碼都散著強，畢竟學習和認知也是需要一定程序的，最重要的是自己能夠主動去悟，我見過一些程式員，其實也沒寫過多少東西，一見別人的代碼就開始各種指責，什么代碼不純粹啊、不夠OO啊、不是DDD啊，碰到這種人您都不用理他，不是鍵盤俠就近親出來的，您讓他寫一段讓我們學習學習，人家總是能裝出一副玄學大師的樣：你？不行，我這種水平的代碼你怎么可能會懂……

　　本來是在講領域服務，不過還是歪到了OOP上，不過我個人覺得思想是技術的前提，后者千變萬化但萬變不離其宗，所以掌握思想很重要，其實也不是說工程師的水平不行或不夠聰明，主要是現在的好多書上沒給出如何做OOP的案例，讓大部分工程師沒吃過豬肉也沒見過豬跑，寫書的人都有一個前提：您已經知道如何做面向物件編程了，我估計是把面向物件編程與面向物件語言搞混了，反正我是覺得您沒有OOP的基礎，上述的代碼肯定要比現實中的簡單，可是這種文章我也不太可能把專案上的代碼貼出來，會出事兒的……在有些人的眼里，簡單的代碼是學不到東西的，這想法其實特別扯，Linux有全部的開源，看完了他也成不了大師，作為演示，我使用了一些簡單的案例，只要能說明問題即可，還是那句話：最重要的是思想，不要總是追求所謂的正宗、權威，最早的那本DDD書籍也是以強調思想為主，有了指導就需要您自己發揮自己的智慧，包括本系列文章，能給出的也是參考，學習到了一個程度就需要集百家之長來彌補自身的不足，不能再等著別人的指導了，那東西哪有個頭兒 ？我這寫寫就開始歪樓，主要是這些問題的確是阻礙我們進步的絆腳石，想學習好實踐是一方面，思想也需要進行改造的，

三、使用模式

　　回歸正文， 我在前面的章節中也提到了領域服務的使用模式：嚴格和松散，松散的模式比較簡單，您在應用服務中可以直接使用物體也可以直接使用領域服務來完成某個業務，很多人都這么用包括我，所以沒什么可說的；而嚴格的模式則要求應用服務不能直接呼叫物體的方法，需要執行什么業務邏輯應該交由領域服務進行代理，如下圖所示，

　　這種模式在領域服務與物體間又做了一個隔離，我個人覺得這種隔離并沒有產生很大的效果，畢竟你還是需要在應用服務中參考物體的，最起碼你得把領域物體查詢出來吧？反而是業務組合的效果比較好，在代碼的復用度方面效果相對突出，比如上圖中的“領域服務B”，這兩種使用模式不屬于強制規則，和“物體中不能訪問DAO”不一樣，具體怎么使用還是得看需要，

總結

　　本章主要講解了業務服務及OOP的一些思想，在實際專案中務必要注意其使用方式，錯誤的使用應用服務很容易導致物體變成了貧血模型，面向物件也就變成了變身程序，另外一條需要提醒的是，在使用業務服務的時候還是要盡量在里面少寫業務邏輯，協調任務才是他應該要干的事兒，

標籤：領域驅動設計

上一篇：OAuth 授權協議 | 都云原生時代了，我們應該多懂一點OAuth ？

下一篇：設計模式之解釋器模式