1. 引言

限界上下文可以拆分為兩個詞，限界和上下文。
限界：是指一個界限，具體的某一個範圍。
上下文：個人理解就是語境。

比如我們常說的段子：

“我想靜靜。”
這個句子一般是想表達“我想靜一靜”的意思。但是我們卻把它玩笑成“靜靜是誰？”。
可見上下文語境很重要。

這個例子只是個開胃菜，我們接著往下看。

2. 案例分析

整個應用程式之內的一個概念性邊界。
邊界之內的每種領域術語、片語或句子--也即通用語言，都有確定的上下文含義。
邊界之外，這些術語可能表示不同的意思。

每次看到這種解釋就頭大。我們還是結合我們的案例來聊一聊吧。

根據上一節對領域的剖析，我們把案例主要拆分成幾個子域，其中銷售子域是核心域，商品子域和物流子域為支撐子域。在這三個子域中，都要和商品打交道。如果把商品抽象為Product物件的話，按我們一般的常規思路（拋開子域的劃分）來說，不管是商品銷售還是發貨，我們都可以共用同一個Product物件。
但在DDD中，在商品子域和銷售子域中，可以共享這個Product物件，但在物流子域，就有點大材小用。為什麼呢？因為畢竟物流子域關注的是商品的發貨處理和物流跟蹤。針對發貨流程而言，我只關心商品的數量、大小、重量等規格，而不必瞭解商品的價格等其他資訊。所以說物流子域應該關注的是貨物的發貨處理而不是商品。

那為什麼我們之前的開發思路會共用同一個Product物件呢？
答案很簡單，沒有進行領域的劃分。把整個專案一概而論，統一建模導致的結果。

在DDD的思想下，當劃分子域之後，每個子域都對應有各自的上下文。在銷售子域和商品子域所在的上下文語境中，商品就是商品，無二義性。在物流子域的上下文語境中，我們也可以說商品的發貨處理，但這時的商品就特指貨物了。確定了真實面目之後，我想我們也會不由自主的抽象一個新的Cargo物件來處理物流相關的業務。這也是DDD帶來的好處，讓我們更清晰的建模。

3. 限界上下文的命名

限界上下文只是一個統一的命名，在我們劃分子域後，每個子域一般對應一個上下文，也可以對應多個上下文。但如果子域對應多個上下文的時候，就要考慮一下是不是子域能否繼續劃分。
命名方式很簡單，領域名+上下文。
比如我們的銷售子域對應銷售上下文，物流子域對應物流上下文。

4. 總結

透過我們上面的舉例分析，限界上下文也並不是一個高深的概念。
用官話來說限界上下文主要用來封裝通用語言和領域物件。
按我個人的理解它就是用來為領域提供上下文語境，保證在領域之內的一些術語、業務相關物件等（通用語言）有一個確切的含義，沒有二義性。

參考資料

In a perfect world, each bounded context has its own models/entities. You wouldn't relate models/entities across bounded contexts. Instead, model x from boundary y, would communicate with boundary z via some sort of api.
This ensures a clear distinction between contexts and removes dependencies. The great benefit of this is, if you have a large application, you can segregate parts of your application to not be critically based on other parts of the application, particularly between businesses.

As a rather obvious example - you don't connect with Facebook's user records - it's a completely different context. You consume the API they provide in order to get the information you need. Think of your application in the same way. When you consume their service, you'd actually write a repository or something that would manage those queries, and code in protection mechanisms in case something goes wrong.

作者：聖傑
連結：