實體物件和值物件都寫完了，本想開始寫資源倉庫順便把工作單元再搞搞。不過有一點麻煩的是我不太想把工作單元作為單獨的一章來寫，一是這東西網上相關的內容太多；二是有的時候使用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的一些思想，在實際專案中務必要注意其使用方式，錯誤的使用應用服務很容易導致實體變成了貧血模型，物件導向也就變成了變身過程。另外一條需要提醒的是，在使用業務服務的時候還是要儘量在裡面少寫業務邏輯，協調任務才是他應該要乾的事兒。