之前看過領域設計一本書，還寫過讀書心得物臂，從理論上介紹了領域設計的一些思路和方法論。
http://www.reibang.com/p/712a49baf468
這里更多的是從實踐的角度去落地領域設計的方法产上。
從領域設計到實踐本人總結了幾個階段：
- 構建領域詞匯表
- 事件風暴會議
- 業(yè)務拆分
- 模型設計
構建領域詞匯表：解決溝通障礙
目標就是統(tǒng)一領域專家棵磷，產(chǎn)品經(jīng)理，業(yè)務開發(fā)晋涣，測試等多個崗位的語言仪媒，
減少溝通的障礙，便于理解谢鹊。
通常為了方便程序員之間溝通算吩，領域詞匯表會中英兩份，英文詞匯還會對應代碼中的Class類名佃扼，成員變量名偎巢。
比如，一個機器學習系統(tǒng)兼耀，
常見的領域詞匯表：
數(shù)據(jù)集 -- dataset
模型 -- model
機器學習 -- MachineLearning
訓練 -- train
預測 -- predict
特征 -- feature
數(shù)據(jù)清洗 -- Data cleaning
致性檢查 -- consistency check
估算 -- estimation
整例 / 變量刪除 -- casewise / variable deletion
成對刪除 - pairwise deletion
探索性分析 -- EDA
再比如压昼，一個下單系統(tǒng)
商家/訂單/用戶/地址/商品 等等
如果系統(tǒng)是0-1的階段求冷，領域詞匯可以由領域專家來節(jié)點，表達和含義窍霞。
如果系統(tǒng)已經(jīng)過了0-1的階段匠题，建議回顧歷史系統(tǒng)，也就是直接進入到領域事件的梳理官撼，就是下一個階段梧躺。
事件風暴會議：拆分事件對象關系條件
圍繞事件不斷的拓展業(yè)務內(nèi)容。
比如傲绣，針對一個訂單系統(tǒng)的事件風暴掠哥，
訂單系統(tǒng)中有很多事件，如果已經(jīng)是一個成熟系統(tǒng)了秃诵，可以直接看下代碼中的ENUM定義续搀，
已經(jīng)接單，已經(jīng)就緒菠净，已經(jīng)下單禁舷，已經(jīng)派送，已經(jīng)送達毅往。圍繞一個“已經(jīng)下單”的領域事件牵咙，領域風暴會議可能會畫出如下一張圖。
比如：
- 事件：下單事件
- 圍繞事件攀唯，產(chǎn)生了領域的對象（領域詞匯對應的對象）：
- 用戶
- 地址
- 商店
- 訂單
- 商品
- 不斷把領域詞匯聚集起來洁桌，形成聚合根，比如商品
在一個成熟的團隊中侯嘀，領域風暴事件中每個顏色代表一層含義另凌。比如上面這個示意圖中。
- 紅色： 代表中心的領域事件
- 藍色： 代表事件處罰的條件
- 黃色： 代表領域對象
- 紫色： 代表聚合根
這個顏色的含義戒幔，一般來自團隊之間的磨合產(chǎn)生的習慣吠谢。非必須。
如果一個系統(tǒng)是0-1诗茎，怎么組織一次事件風暴會議工坊，
一個常用的手段是利用主流程來拆分。
比如一個機器學習系統(tǒng)：
導入數(shù)據(jù) --> 數(shù)據(jù)加工 --> 觸發(fā)學習 --> 學習完成 --> 模型評估 --> 模型發(fā)布敢订。
比如一個訂單系統(tǒng)：
添加商品 --> 下單 --> 商家接單 --> 商家發(fā)貨 --> 騎手接單--> 騎手送達 -->確認收貨王污。
業(yè)務拆分：DDD到微服務
事件風暴會結合每個事件，不斷的拆分出領域對象枢析，
然后講相關的對象聚合在一起玉掸，區(qū)分行為。但是到具體的服務設計之后醒叁。
會再劃分出子領域司浪，每個子領域對應一個或者一組相關的微服務泊业。
不同組的微服務之間有明確的界限來劃分自己的指責，同時多個微服務構成了一個大的系統(tǒng)啊易。
比如吁伺，還是之前的下單的業(yè)務場景。
“下單”是一個子領域
圍繞下單這個主題租谈，會形成一個核心的主題域處理下單
但是圍繞下單篮奄，還有用戶的操作，商家的操作相關操作作為支撐割去。
所以拆分關系是：
綠色是這個子領域的一個核心主題服務窟却，灰色是這個子領域的支撐服務，微服務的設計
- 用戶 可作為一個微服務呻逆，支撐訂單這個核心服務
- 商家 可作為一個微服務夸赫，支撐訂單這個核心服務
- 訂單 可作為一個微服務
貧血模型和充血模型設計：表和服務接口
領域對象的設計，先設計核心層咖城，核心層結束后
針對持久化層設計DO茬腿，
針對傳輸對象設計DTO，
針對業(yè)務表現(xiàn)層設計VO宜雀，
設計核心領域對象的時候切平，可以用貧血模型，也可以用充血模型辐董。
比如貧血模型設計訂單這個領域對象悴品。
“貧血模型設計 ” ： 數(shù)據(jù)邏輯分開，數(shù)據(jù)即領域郎哭，service對應領域對象的行為他匪，對象關系的封裝菇存。
- 商家DO
- 商家id
- 商家name
- 商品id
- 商品DO
- 商品id
- 商品name
- 商品價格 price
- 商家Service
- 商品Service
- get商品夸研，從商家service和商品service分別獲取兩個entity，做組裝
“充血模型設計” ：增加一個Domain層依鸥，把數(shù)據(jù)和方法封裝為Domain
- 商品Object
- 商品id
- 商品name
- 商家id
- 商品DAO
- 商品Domain： 數(shù)值 + 方法亥至，DAO的調(diào)用 + 邏輯的組裝
- 商品service
- getEntity，Domain里面獲取所有需要的值
tips：很多人會問到貧血模型和充血模型有什么差別贱迟，用自己的理解方式姐扮，本質是一樣的，貧血模型的封裝性體現(xiàn)在service層衣吠，而充血模型多了一個domain層茶敏，領域的封裝性放到了domain層而已。
當然大家也可以用網(wǎng)上“面向面試”的回答方式：貧血模型數(shù)據(jù)和service分離缚俏，充血模型數(shù)據(jù)和service統(tǒng)一惊搏。
補充：微服務的治理
這里不是重點贮乳，只提一下和領域設計相關的是多個服務之間的解耦，必要的兩個技術是：
- 消息隊列：一個訂單事件再多個服務之間流轉恬惯，通常是通過訂單消息來通知各個服務向拆。
- 注冊中心：微服務之間通常不感知哪個物理服務上線和下線，通常通過注冊和發(fā)現(xiàn)來調(diào)用具體的服務酪耳。
消息對接和注冊中心這里不過多介紹了浓恳，如果不了解還請查閱相關資料。
