DDD理論學習系列（3）-- 限界上下文

1. 引言

限界上下文能夠拆分爲兩個詞，限界和上下文。
限界：是指一個界限，具體的某一個範圍。
上下文：我的理解就是語境。

好比咱們常說的段子：

「我想靜靜。」
這個句子通常是想表達「我想靜一靜」的意思。可是咱們卻把它玩笑成「靜靜是誰？」。
可見上下文語境很重要。

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

2. 案例分析

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

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

根據上一節對領域的剖析，咱們把案例主要拆分紅幾個子域，其中銷售子域是核心域，商品子域和物流子域爲支撐子域。在這三個子域中，都要和商品打交道。若是把商品抽象爲Product對象的話，按咱們通常的常規思路（拋開子域的劃分）來講，無論是商品銷售仍是發貨，咱們均可以共用同一個Product對象。
但在DDD中，在商品子域和銷售子域中，能夠共享這個Product對象，但在物流子域，就有點大材小用。爲何呢？由於畢竟物流子域關注的是商品的發貨處理和物流跟蹤。針對發貨流程而言，我只關心商品的數量、大小、重量等規格，而沒必要了解商品的價格等其餘信息。因此說物流子域應該關注的是貨物的發貨處理而不是商品。
那爲何咱們以前的開發思路會共用同一個Product對象呢？
答案很簡單，沒有進行領域的劃分。把整個項目一律而論，統一建模致使的結果。
在DDD的思想下，當劃分子域以後，每一個子域都對應有各自的上下文。在銷售子域和商品子域所在的上下文語境中，商品就是商品，無二義性。在物流子域的上下文語境中，咱們也能夠說商品的發貨處理，但這時的商品就特指貨物了。肯定了真實面目以後，我想咱們也會不禁自主的抽象一個新的Cargo對象來處理物流相關的業務。這也是DDD帶來的好處，讓咱們更清晰的建模。

3. 限界上下文的命名

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

4. 總結

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