1. 引言
限界上下文可以拆分為兩個詞，限界和上下文。
限界：是指一個界限，具體的某一個范圍。
上下文：個人理解就是語境。
比如我們常說的段子：
“我想靜靜。”
這個句子一般是想表達“我想靜一靜”的意思。但是我們卻把它玩笑成“靜靜是誰？”。
可見上下文語境很重要。
這個例子只是個開胃菜，我們接着往下看。
2. 案例分析
整個應用程序之內的一個概念性邊界。
邊界之內的每種領域術語、詞組或句子--也即通用語言，都有確定的上下文含義。
邊界之外，這些術語可能表示不同的意思。
每次看到這種解釋就頭大。我們還是結合我們的案例來聊一聊吧。
根據上一節對領域的剖析，我們把案例主要拆分成幾個子域，其中銷售子域是核心域，商品子域和物流子域為支撐子域。在這三個子域中，都要和商品打交道。如果把商品抽象為Product對象的話，按我們一般的常規思路（拋開子域的划分）來說，不管是商品銷售還是發貨，我們都可以共用同一個Product對象。
但在DDD中，在商品子域和銷售子域中，可以共享這個Product對象，但在物流子域，就有點大材小用。為什么呢？因為畢竟物流子域關注的是商品的發貨處理和物流跟蹤。針對發貨流程而言，我只關心商品的數量、大小、重量等規格，而不必了解商品的價格等其他信息。所以說物流子域應該關注的是貨物的發貨處理而不是商品。
那為什么我們之前的開發思路會共用同一個Product對象呢？
答案很簡單，沒有進行領域的划分。把整個項目一概而論，統一建模導致的結果。
在DDD的思想下，當划分子域之后，每個子域都對應有各自的上下文。在銷售子域和商品子域所在的上下文語境中，商品就是商品，無二義性。在物流子域的上下文語境中，我們也可以說商品的發貨處理，但這時的商品就特指貨物了。確定了真實面目之后，我想我們也會不由自主的抽象一個新的Cargo對象來處理物流相關的業務。這也是DDD帶來的好處，讓我們更清晰的建模。
3. 限界上下文的命名
限界上下文只是一個統一的命名，在我們划分子域后，每個子域一般對應一個上下文，也可以對應多個上下文。但如果子域對應多個上下文的時候，就要考慮一下是不是子域能否繼續划分。
命名方式很簡單，領域名+上下文。
比如我們的銷售子域對應銷售上下文，物流子域對應物流上下文。
4. 總結
通過我們上面的舉例分析，限界上下文也並不是一個高深的概念。
用官話來說限界上下文主要用來封裝通用語言和領域對象。
按我個人的理解它就是用來為領域提供上下文語境，保證在領域之內的一些術語、業務相關對象等（通用語言）有一個確切的含義，沒有二義性。