你是否還在爲微服務應該拆多小而爭論不休?到底如何才能設計出收放自如的微服務?怎樣才能保證業務領域模型與代碼模型的一致性?或許本文能幫你找到答案。
本文是基於 DDD 的微服務設計和開發實戰篇，通過借鑑領域驅動設計思想，指導微服務項目團隊進行設計和開發(理論篇詳見《當中臺遇上 DDD，我們該如何設計微服務?》)。本文包括三部分內容：第一部分講述領域驅動設計基本知識，包括：分層架構、服務視圖、數據視圖和領域事件發佈和訂閱等;第二部分講述微服務設計方法、過程、模板、代碼目錄、設計原則等內容;最後部分以一個項目爲例講述基於 DDD 的微服務設計過程。
1
目標
本文采用 DDD(領域驅動設計)作爲微服務設計指導思想，通過事件風暴建立領域模型，合理劃分領域邏輯和物理邊界，建立領域對象及服務矩陣和服務架構圖，定義符合 DDD 分層架構思想的代碼結構模型，保證業務模型與代碼模型的一致性。通過上述設計思想、方法和過程，指導團隊按照 DDD 設計思想完成微服務設計和開發。
通過領域模型和 DDD 的分層思想，屏蔽外部變化對領域邏輯的影響，確保交付的軟件產品是邊界清晰的微服務，而不是內部邊界依然混亂的小單體。在需求和設計變化時，可以輕鬆的完成微服務的開發、拆分和組合，確保微服務不易受外部變化的影響，並穩定運行。
2
適用範圍
本文適用於按照 DDD 設計方法進行微服務設計和開發的項目及相關人員。
以下情況不適用：
“我們的目標是按期蓋出一棟大樓來，不要跟我提什麼方法，有這囉嗦的時間，還不如抓緊點時間搬磚，把樓給我快點蓋好!”。
“我的工作就是讓軟件運行起來，能工作一切就 OK!我不需要那麼多約束，什麼設計方法、擴展性、業務變化、領域模型、響應能力與我無關。別耽誤工期啦!先上線再說!”。
“好的軟件是自己演進出來的，我們不需要設計!”。
哈哈，開個玩笑啦!其實設計不會花太多時間的!
不耽誤大家時間了，言歸正傳。
3
DDD 分層架構視圖
DDD 分層架構包括：展現層、應用層、領域層和基礎層。
DDD 分層架構各層職能如下：
展現層
展現層負責向用戶顯示信息和解釋用戶指令。
應用層
應用層是很薄的一層，主要面向用戶用例操作，協調和指揮領域對象來完成業務邏輯。應用層也是與其他系統的應用層進行交互的必要渠道。應用層服務儘量簡單，它不包含業務規則或知識，只爲下一層的領域對象協調任務，使它們互相協作。應用層還可進行安全認證、權限校驗、分佈式和持久化事務控制或向外部應用發送基於事件的消息等。
領域層
領域層是軟件的核心所在，它實現全部業務邏輯並且通過各種校驗手段保證業務正確性。它包含業務所涉及的領域對象(實體、值對象)、領域服務以及它們之間的關係。它負責表達業務概念、業務狀態以及業務規則，具體表現形式就是領域模型。
基礎層
基礎層爲各層提供通用的技術能力，包括：爲應用層傳遞消息、提供 API 管理，爲領域層提供數據庫持久化機制等。它還能通過技術框架來支持各層之間的交互。
4
服務視圖
微服務內的服務視圖
微服務內有 Facade 接口、應用服務、領域服務和基礎服務，各層服務協同配合，爲外部提供服務。
1、接口服務
接口服務位於用戶接口層，用於處理用戶發送的 Restful 請求和解析用戶輸入的配置文件等，並將信息傳遞給應用層。
2、應用服務
應用服務位於應用層。用來表述應用和用戶行爲，負責服務的組合、編排和轉發，負責處理業務用例的執行順序以及結果的拼裝。
應用層的服務包括應用服務和領域事件相關服務。
應用服務可對微服務內的領域服務以及微服務外的應用服務進行組合和編排，或者對基礎層如文件、緩存等數據直接操作形成應用服務，對外提供粗粒度的服務。
領域事件服務包括兩類：領域事件的發佈和訂閱。通過事件總線和消息隊列實現異步數據傳輸，實現微服務之間的解耦。
3、領域服務
領域服務位於領域層，爲完成領域中跨實體或值對象的操作轉換而封裝的服務，領域服務以與實體和值對象相同的方式參與實施過程。
領域服務對同一個實體的一個或多個方法進行組合和封裝，或對多個不同實體的操作進行組合或編排，對外暴露成領域服務。領域服務封裝了核心的業務邏輯。實體自身的行爲在實體類內部實現，向上封裝成領域服務暴露。
爲隱藏領域層的業務邏輯實現，所有領域方法和服務等均須通過領域服務對外暴露。
爲實現微服務內聚合之間的解耦，原則上禁止跨聚合的領域服務調用和跨聚合的數據相互關聯。
4、基礎服務
基礎服務位於基礎層。爲各層提供資源服務(如數據庫、緩存等)，實現各層的解耦，降低外部資源變化對業務邏輯的影響。
基礎服務主要爲倉儲服務，通過依賴反轉的方式爲各層提供基礎資源服務，領域服務和應用服務調用倉儲服務接口，利用倉儲實現持久化數據對象或直接訪問基礎資源。鄭州×××醫院×××：http://mobile.zzchanghong110.com/