限界上下文可以拆分為兩個詞，限界和上下文。
限界：是指乙個界限，具體的某乙個範圍。
上下文：個人理解就是語境。
比如我們常說的段子：
「我想靜靜。」這個例子只是個開胃菜，我們接著往下看。這個句子一般是想表達「我想靜一靜」的意思。但是我們卻把它玩笑成「靜靜是誰？」。
可見上下文語境很重要。
整個應用程式之內的乙個概念性邊界。每次看到這種解釋就頭大。我們還是結合我們的案例來聊一聊吧。邊界之內的每種領域術語、片語或句子--也即通用語言，都有確定的上下文含義。
邊界之外，這些術語可能表示不同的意思。
根據上一節對領域的剖析，我們把案例主要拆分成幾個子域，其中銷售子域是核心域，商品子域和物流子域為支撐子域。在這三個子域中，都要和商品打交道。如果把商品抽象為product物件的話，按我們一般的常規思路（拋開子域的劃分）來說，不管是商品銷售還是發貨，我們都可以共用同乙個product物件。
但在ddd中，在商品子域和銷售子域中，可以共享這個product物件，但在物流子域，就有點大材小用。為什麼呢？因為畢竟物流子域關注的是商品的發貨處理和物流跟蹤。針對發貨流程而言，我只關心商品的數量、大小、重量等規格，而不必了解商品的**等其他資訊。所以說物流子域應該關注的是貨物的發貨處理而不是商品。
那為什麼我們之前的開發思路會共用同乙個product物件呢？
答案很簡單，沒有進行領域的劃分。把整個專案一概而論，統一建模導致的結果。
在ddd的思想下，當劃分子域之後，每個子域都對應有各自的上下文。在銷售子域和商品子域所在的上下文語境中，商品就是商品，無二義性。在物流子域的上下文語境中，我們也可以說商品的發貨處理，但這時的商品就特指貨物了。確定了真實面目之後，我想我們也會不由自主的抽象乙個新的cargo物件來處理物流相關的業務。這也是ddd帶來的好處，讓我們更清晰的建模。
限界上下文只是乙個統一的命名，在我們劃分子域後，每個子域一般對應乙個上下文，也可以對應多個上下文。但如果子域對應多個上下文的時候，就要考慮一下是不是子域能否繼續劃分。
命名方式很簡單，領域名+上下文。
比如我們的銷售子域對應銷售上下文，物流子域對應物流上下文。
通過我們上面的舉例分析，限界上下文也並不是乙個高深的概念。
用官話來說限界上下文主要用來封裝通用語言和領域物件。
按我個人的理解它就是用來為領域提供上下文語境，保證在領域之內的一些術語、業務相關物件等（通用語言）有乙個確切的含義，沒有二義性。
DDD理論學習系列（3） 限界上下文
限界上下文可以拆分為兩個詞，限界和上下文。限界 是指乙個界限，具體的某乙個範圍。上下文 個人理解就是語境。比如我們常說的段子 我想靜靜。這個句子一般是想表達 我想靜一靜 的意思。但是我們卻把它玩笑成 靜靜是誰？可見上下文語境很重要。這個例子只是個開胃菜，我們接著往下看。整個應用程式之內的乙個概念性邊...
DDD之領域，子域，限界上下文
從廣義上來講，領域即是乙個組織所做的事情以及其中所包含的一切。一般來講商業機構會確定乙個市場，然後在這個市場中銷售產品和服務。每個組織都有它自己的業務範圍和做事方式，這個業務範圍以及在其中所進行的活動就是領域。由於領域的概念通常都過大，所以我們一般都會將其進行拆分，諸如核心域，通用域，支援域。一般來...
DDD 領域驅動設計中的限界上下文
承接上文，我們知道了，在確定好研究的領域後，我們可以進行粗粒度的拆分，可以將領域拆分成不同的子域，不同的子域又承擔著不同的業務職責，根據重要性，可以將子域分為 核心域 支撐域和通用域，一般來說，我們要將重點放到核心域的開發與整合上。在ddd中，乙個領域被分為若干子域，領域模型是在特定的場景中來設計的...