上圖是一張普通地圖，最刺眼的就是邊界？ 非常好奇地圖繪製工程師是如何描繪如此彎曲多變的邊界的？強制行政區域還是人群歷史原因自然的人以群分？ 我們再換個視角，對工程師或者架構師來說，微服務的邊界如何劃分呢？ 基於DDD設計方法論中的概念 限界上下文 來劃分微服務的邊界； 背景 架構師小李正在團隊推行D ...
上圖是一張普通地圖，最刺眼的就是邊界？
非常好奇地圖繪製工程師是如何描繪如此彎曲多變的邊界的？強制行政區域還是人群歷史原因自然的人以群分？
我們再換個視角，對工程師或者架構師來說，微服務的邊界如何劃分呢？
基於DDD設計方法論中的概念 限界上下文 來劃分微服務的邊界；
背景
架構師小李正在團隊推行DDD設計方法論,領域建模和系統建設過程中，很多崗位需要參加進來，比如產品經理，領域專家，項目經理，架構師，開發經理，測試經理。對同樣的領域知識，不同的人可能有不同的認識，交流起來存在一定障礙。
假如你是小李，你會如何消除這種交流障礙呢？
答案是今天的主角：通用語言和限界上下文。
先簡單的釐清這兩個概念。
| 名詞 | 概念 |
|---|---|
| 通用語言 | 定義上下文含義 |
| 限界上下文 | 定義領域的邊界，確保每個上下文的語義（通用語言）在邊界內的唯一性含義 |
下麵，我們拿顯微鏡來看看到底什麼是通用語言？限界上下文又是什麼東西？
通用語言
通用語言：團隊交流達成共識的能夠明確簡單清晰的描述業務規則和業務含義的語言就是通用語言。
用途：通用語言是團隊的統一語言，在團隊中不管你是什麼角色，在同一領域的軟體生命周期里都使用統一語言進行交流。
價值：
- 解決各崗位的溝通障礙問題，促進不同崗位的和合作，確保業務需求的正確表達。
- 通用語言貫穿於整個設計過程，基於通用語言可以開發出可讀性更好的代碼，能準確的把業務需求轉化為代碼。
類比： 義勇軍對中國人來說就是通用語言，大家都知道這是我們的國歌，沒有二義性；
通用語言的組成：
| 組成部分 | 說明 | 代碼對應 |
|---|---|---|
| 術語 | 名詞：給領域命名，比如訂單，商品；動詞：給命令和事件命名； | 名詞：對應實體動詞：命令或者事件 |
DDD領域建模和系統落地過程：
既然是一種映射，那麼可以整理成一張表格。
記錄事件風暴中產生的領域對象的位置，屬性和在代碼模型中對應的代碼對象的對應關係。
格式如下：
要點：DDD的設計和分析的過程中，要保證術語在限界上下文中的統一，並保證業務模型中的領域對象跟系統模型中的代碼對象一一對應。從而保證業務模型跟代碼模型的一致性。
限界上下文
定義：戰略設計中確定語義所在的領域邊界就是限界上下文。
為了好理解，這裡對比一下中文和DDD：
| 對比項目 | 語言 | 語義環境 |
|---|---|---|
| 中文 | 漢語 | 語言環境 |
| DDD | 通用語言 | 限界上下文 |
限界：即邊界上下文：即語義環境；
綜合起來：即帶邊界的語義環境。
限界上下文是微服務拆分和設計的主要邊界依據，當然微服務還有其他的劃分邊界依據，需要綜合考慮；我們將限界上下文內的領域模型映射到微服務就完成了從問題域到軟體的解決方案。
小結
問題？
為什麼有限界上下文的概念，除瞭解決交流障礙，還有什麼更具體的原因嗎？ 確定了領域的邊界，是微服劃分的主要依據 封裝了領域模型 通用語言，確定了模型的邊界哪些該做哪些不該做
限界上下文在微服務設計的作用和意義？ 微服務邊界劃分的主要依據
最後小結彙總成一張圖。
原創不易，關註誠可貴，轉發價更高！轉載請註明出處，讓我們互通有無，共同進步，歡迎溝通交流。
我會持續分享Java軟體編程知識和程式員發展職業之路，歡迎關註，我整理了這些年編程學習的各種資源，關註公眾號‘李福春持續輸出’，發送'學習資料'分享給你！
