上圖是一張普通地圖，最刺眼的就是邊界？ 非常好奇地圖繪製工程師是如何描繪如此彎曲多變的邊界的？強制行政區域還是人群歷史原因自然的人以群分？ 我們再換個視角，對工程師或者架構師來說，微服務的邊界如何劃分呢？
基於ddd設計方**中的概念 限界上下文 來劃分微服務的邊界；
架構師小李正在團隊推行ddd設計方**,領域建模和系統建設過程中，很多崗位需要參加進來，比如產品經理，領域專家，專案經理，架構師，開發經理，測試經理。對同樣的領域知識，不同的人可能有不同的認識，交流起來存在一定障礙。 假如你是小李，你會如何消除這種交流障礙呢？
答案是今天的主角：通用語言和限界上下文。 先簡單的釐清這兩個概念。
名詞概念
通用語言
定義上下文含義
限界上下文
定義領域的邊界，確保每個上下文的語義（通用語言）在邊界內的唯一性含義
下面，我們拿顯微鏡來看看到底什麼是通用語言？限界上下文又是什麼東西？
通用語言：團隊交流達成共識的能夠明確簡單清晰的描述業務規則和業務含義的語言就是通用語言。用途：通用語言是團隊的統一語言，在團隊中不管你是什麼角色，在同一領域的軟體生命週期裡都使用統一語言進行交流。 價值：
解決各崗位的溝通障礙問題，促進不同崗位的和合作，確保業務需求的正確表達。
通用語言貫穿於整個設計過程，基於通用語言可以開發出可讀性更好的**，能準確的把業務需求轉化為**。
通用語言的組成：
組成部分
說明**對應
術語名詞：給領域命名，比如訂單，商品；動詞：給命令和事件命名；
名詞：對應實體動詞：命令或者事件
要點：ddd的設計和分析的過程中，要保證術語在限界上下文中的統一，並保證業務模型中的領域物件跟系統模型中的**物件一一對應。從而保證業務模型跟**模型的一致性。
定義：戰略設計中確定語義所在的領域邊界就是限界上下文。 為了好理解，這裡對比一下中文和ddd：
對比專案
語言語義環境
中文漢語
語言環境
ddd通用語言
限界上下文
限界：即邊界上下文：即語義環境； 綜合起來：即帶邊界的語義環境。 限界上下文是微服務拆分和設計的主要邊界依據，當然微服務還有其他的劃分邊界依據，需要綜合考慮；我們將限界上下文內的領域模型對映到微服務就完成了從問題域到軟體的解決方案。
問題？ 為什麼有限界上下文的概念，除了解決交流障礙，還有什麼更具體的原因嗎？ 確定了領域的邊界，是微服劃分的主要依據 封裝了領域模型 通用語言，確定了模型的邊界哪些該做哪些不該做
限界上下文在微服務設計的作用和意義？ 微服務邊界劃分的主要依據
最後小結彙總成一張圖。
DDD之領域，子域，限界上下文
從廣義上來講，領域即是乙個組織所做的事情以及其中所包含的一切。一般來講商業機構會確定乙個市場，然後在這個市場中銷售產品和服務。每個組織都有它自己的業務範圍和做事方式，這個業務範圍以及在其中所進行的活動就是領域。由於領域的概念通常都過大，所以我們一般都會將其進行拆分，諸如核心域，通用域，支援域。一般來...
DDD 領域驅動設計中的限界上下文
承接上文，我們知道了，在確定好研究的領域後，我們可以進行粗粒度的拆分，可以將領域拆分成不同的子域，不同的子域又承擔著不同的業務職責，根據重要性，可以將子域分為 核心域 支撐域和通用域，一般來說，我們要將重點放到核心域的開發與整合上。在ddd中，乙個領域被分為若干子域，領域模型是在特定的場景中來設計的...
DDD中的領域 子域和限界上下文的說明
領域 領域即是乙個組織所做的事情以及其中所包含的一切。每個組織都有它自己的業務範圍和做事方式。這個業務範圍以及在其中所進行的活動便是領域。當你為某個組織開發軟體時，你面對的便是這個組織的領域。這個領域對你來說應該是清晰的，因為你在此工作。領域既可以表示整個業務系統，也可以表示其中的某個核心域或者支撐...