歡迎你們關注公衆號「JAVA前線」查看更多精彩分享文章，主要包括源碼分析、實際應用、架構思惟、職場分享、產品思考等等，歡迎你們加我微信「java_front」一塊兒交流學習java
0 文章概述
領域驅動設計DDD是一段時間以來比較流行的概念，剛開始接觸時以爲概念不少，比較難以落地。本文就來分析探討DDD落地時須要關注的六個問題，並經過一個足球運動員信息管理系統案例分析落地的六個步驟。數據庫
1 六個問題
1.1 爲何使用
DDD方法論的核心是將問題不斷分解，把大問題分解爲小問題，大業務分解小領域，簡而言之就是分而治之，各個擊破。設計模式
分而治之是指直接面對大業務咱們無從下手，須要按照必定方法進行分解，分解爲高內聚的小領域，使得業務有邊界清晰，而這些小領域是咱們有能力處理的，這就是領域驅動設計的核心。緩存
各個擊破是指當問題被拆分爲小領域後，由於小領域業務內聚，其子領域高度相關，咱們在技術維度能夠對其進行詳細設計，在管理維度能夠按照領域對項目進行分工。須要指出DDD不能替代詳細設計，DDD是爲了更清晰地詳細設計。微信
在微服務流行的互聯網行業，當業務逐漸複雜時，技術人員須要解決如何劃分微服務邊界的問題，DDD這種清晰化業務邊界的特性正好能夠用來解決這個問題。數據結構
1.2 方法與目標
咱們的目標是將業務劃分清晰的邊界，而DDD是達成目標的有效方法之一，這一點是須要格外注意的。DDD是方法不是目標，不須要爲了使用而使用。例如業務模型比較簡單能夠很容易分析的業務就不須要使用DDD，還有一些目標是快速驗證類型的項目，追求短平快，前期可能也不須要使用領域驅動設計。架構
1.3 總體與局部
領域能夠劃分多個子領域，子域能夠再劃分多個子子域，限界上下文本質上也是一種子子域，那麼在業務分解時一個業務模塊究竟是領域、子域仍是子子域？框架
我認爲不用糾結在這個問題，由於這取決於看待這個模塊的角度。你認爲總體多是別人的局部，你認爲的局部多是別人的總體，叫什麼名字不重要，最重要的是按照高內聚原則將業務高度相關的模塊收斂。dom
1.4 粒度粗與細
業務劃分粒度的粗細並無統一的標準，仍是要根據業務須要、開發資源、技術實力等因素綜合考量。例如微服務拆分過細反而會增長開發、部署和維護的複雜度，可是拆分過粗可能會致使大量業務高度耦合，開發部署起來是挺快的，可是缺失可維護性和可擴展性，這須要根據實際狀況作出權衡。數據庫設計
1.5 領域與數據
領域對象與數據對象一個重要的區別是值對象存儲方式。在討論領域對象和數據對象以前，咱們首先討論實體和值對象這一組概念。實體是具備惟一標識的對象，而惟一標識會伴隨實體對象整個生命週期而且不可變動。值對象本質上是屬性的集合，並無惟一標識。
領域對象在包含值對象的同時也保留了值對象的業務含義，而數據對象可使用更加鬆散的結構保存值對象，簡化數據庫設計。
如今假設咱們須要管理足球運動員信息，對應的領域模型和數據模型應該如何設計？姓名、身高、體重是一名運動員本質屬性，加上惟一編號能夠對應實體對象。跑動距離，傳球成功率，進球數是運動員比賽中的表現，這些屬性的集合能夠對應值對象。
值對象在數據對象中能夠用鬆散的數據結構進行存儲，而值對象在領域對象中須要保留其業務含義以下圖所示：
根據圖示編寫領域對象與數據對象代碼：
// 數據對象 public class FootballPlayerDO { private Long id; private String name; private Integer height; private Integer weight; private String gamePerformance; } // 領域對象 public class FootballPlayerDMO { private Long id; private String name; private Integer height; private Integer weight; private GamePerformanceVO gamePerformanceVO; } public class GamePerformanceVO { private Double runDistance; private Double passSuccess; private Integer scoreNum; }
1.6 抽象與靈活
抽象的核心是找相同，對不一樣事物提取公因式。實現的核心是找不一樣，擴展各自的屬性和特色。例如模板方法設計模式正是用抽象構建框架，用實現擴展細節。
咱們回到數據模型的討論，能夠發現腳本化是一種拓展靈活性的方式，腳本化不只指使用groovy、QLExpress腳本加強系統靈活性，還包括鬆散可擴展的數據結構。
數據模型抽象出了姓名、身高、體重這些基本屬性，對於頻繁變化的比賽表現屬性，這些屬性值可能常常變化，甚至屬性自己也是常常變化，例如可能會加上射門次數，突破次數，因此採用鬆散的JSON數據結構進行存儲。
2 六個步驟
工程理論老是要落地的，落地也是須要一些步驟和方法的。本文咱們一塊兒分析一個足球運動員信息管理系統，目標是管理運動員從轉會到上場比賽整條鏈路信息，這個系統你們應該也都沒有接觸過，咱們一塊兒來分析。須要說明本實例着重演示DDD方法論如何落地，業務細節可能並不能面面俱到。
2.1 流程梳理
梳理流程有兩個問題須要考慮，第一個問題是從什麼視角去梳理？由於不一樣的人看到的流程是不同的。答案是取決於系統須要解決的是什麼問題，由於咱們要管理運動員從轉會到上場比賽整條鏈路信息，因此從運動員視角出發是一個合適的選擇。
第二個問題是對業務不熟悉怎麼辦？由於咱們不是體育和運動專家，並不清楚整條鏈路的業務細節。答案是梳理流程時必定要有業務專家在場，由於沒有真實業務細節，沒法領域驅動設計。同理在互聯網梳理複雜業務流程時，必定要有對相關業務熟悉的產品經理或者運營一塊兒參與。
足球業務專家梳理出了業務流程，運動員提出轉會，協商一致後到新俱樂部體檢，體檢經過就進行簽約。進入新俱樂部後進行訓練，訓練指標達標後上場比賽，賽後參加新聞發佈會。
2.2 四色建模
(1) 時標對象
四色建模第一種顏色是紅色，表示時標對象。時標對象是四色建模最重要的對象，能夠理解爲核心業務單據。在業務進行過程當中必定要對關鍵業務留下單據，經過這些單據能夠追溯出整個業務流程。
時標對象具備兩個特色：第一是事實不可變性，記錄了過去某個時間點或時間段內發生的事實。第二是責任可追溯性，記錄了管理者關注的信息。如今咱們分析本系統時標對象有哪些，須要留下哪些核心業務單據。
轉會對應轉會單據，體檢對應體檢單據，籤合同對應合同單據，訓練對應訓練指標單據，比賽對應比賽指標單據，新聞發佈會對應採訪單據。根據分析繪製以下時標對象：
(2) 參與方、地、物
這三類對象在四色建模中用綠色表示，咱們以電商場景爲例進行說明。用戶支付購買商家的商品時，用戶和商家是參與方。物流系統發貨時配送單據須要有配送地址對象，地址對象就是地。訂單須要商品對象，物流配送須要有貨品，商品和貨品就是物。
分析本例可知參與方包含總經理、隊醫、教練、球迷、記者，地包含訓練地址、比賽地址、採訪地址，物包含簽名球衣和簽名足球：
(3) 角色對象
在四色建模中用黃色表示，這類對象表示參與方、地、物是以什麼角色參與到業務流程：
(4) 描述對象
咱們能夠爲對象增長相關描述信息，在四色建模中用藍色表示：
2.3 劃分領域
在四色建模過程當中咱們體會到時標對象是最重要的對象，由於其承載了業務系統核心單據。在劃分領域時咱們一樣離不開時標對象，經過收斂相關時標對象劃分領域。
2.4 領域事件
當業務系統發生一件事情時，若是本領域或其它領域有後續動做跟進，那麼咱們把這件事情稱爲領域事件，這個事件須要被感知。
例如球員比賽受傷了，這是比賽子域事件，可是醫療和訓練子域是須要感知的，那麼比賽子域就發出一個事件，醫療和訓練子域會訂閱。
例如球員比賽取得進球，這也是比賽子域事件，可是訓練和合同子域也會關注這個事件，因此比賽子域也會發出一個比賽進球事件，訓練和合同子域會訂閱。
經過事件交互有一個問題須要注意，經過事件訂閱實現業務只能採用最終一致性，須要放棄強一致性，這一點可能會引入新的複雜度須要權衡。
2.5 項目搭建
(1) API
接口層：提供面向外部接口聲明和DTO對象
(2) controller
訪問層：提供HTTP訪問入口
(3) service
業務層：領域層和業務層都包含業務，可是用途不一樣。業務層能夠組合不一樣領域業務，而且能夠增長流控、監控、日誌、權限控制切面，相較於領域層更爲豐富，提供BO對象
(4) domain
領域層：提供DMO（DomainObject）、VO、事件、數據訪問對象，核心是按照領域進行分包，領域內高內聚，領域間低耦合
(5) dependency
外部訪問層：在這個模塊中調用外部RPC服務，解析返回碼和返回數據
(6) infrastructure
基礎層：包含基礎功能，例如緩存工具，消息隊列，分佈式鎖，消息發送等功能
咱們展開領域層進行分析。領域層的核心是按照領域進行分包，而且提供DMO、VO、事件、數據訪問對象，領域內高內聚，領域間低耦合，例如domain1對應合同子域，domain2對應訓練子域，domain3對應合同子域。
2.6 詳細設計
目前爲止領域已經肯定了，如今能夠根據領域劃分任務了，組內成員分別負責一個或多個領域進行詳細設計，這個階段就是你們很是熟悉的用例圖，活動圖，時序圖，數據庫設計，接口設計的用武之地。須要說明的是領域驅動設計不是取代詳細設計，而是爲了更清晰地詳細設計。
3 文章總結
本文探討了DDD落地時須要關注的六個問題，並經過一個足球運動員信息管理系統案例落地了六個步驟。在實際應用中各業務形態千差萬別，可是方法論卻能夠通用，咱們須要明確DDD核心是分而治之各個擊破，並配合一些通過檢驗的有效方法進行建模，但願本文對你們有所幫助。
歡迎你們關注公衆號「JAVA前線」查看更多精彩分享文章，主要包括源碼分析、實際應用、架構思惟、職場分享、產品思考等等，歡迎你們加我微信「java_front」一塊兒交流學習