DDD理論學習系列(3) 限界上下文

2022-01-09 22:53:17 字數 1252 閱讀 1405

限界上下文可以拆分為兩個詞,限界和上下文。

限界:是指乙個界限,具體的某乙個範圍。

上下文:個人理解就是語境。

比如我們常說的段子:

「我想靜靜。」

這個句子一般是想表達「我想靜一靜」的意思。但是我們卻把它玩笑成「靜靜是誰?」。

可見上下文語境很重要。

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

整個應用程式之內的乙個概念性邊界。

邊界之內的每種領域術語、片語或句子--也即通用語言,都有確定的上下文含義。

邊界之外,這些術語可能表示不同的意思。

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

根據上一節對領域的剖析,我們把案例主要拆分成幾個子域,其中銷售子域是核心域,商品子域和物流子域為支撐子域。在這三個子域中,都要和商品打交道。如果把商品抽象為product物件的話,按我們一般的常規思路(拋開子域的劃分)來說,不管是商品銷售還是發貨,我們都可以共用同乙個product物件。

但在ddd中,在商品子域和銷售子域中,可以共享這個product物件,但在物流子域,就有點大材小用。為什麼呢?因為畢竟物流子域關注的是商品的發貨處理和物流跟蹤。針對發貨流程而言,我只關心商品的數量、大小、重量等規格,而不必了解商品的**等其他資訊。所以說物流子域應該關注的是貨物的發貨處理而不是商品。

那為什麼我們之前的開發思路會共用同乙個product物件呢?

答案很簡單,沒有進行領域的劃分。把整個專案一概而論,統一建模導致的結果。

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

限界上下文只是乙個統一的命名,在我們劃分子域後,每個子域一般對應乙個上下文,也可以對應多個上下文。但如果子域對應多個上下文的時候,就要考慮一下是不是子域能否繼續劃分。

命名方式很簡單,領域名+上下文。

比如我們的銷售子域對應銷售上下文,物流子域對應物流上下文。

通過我們上面的舉例分析,限界上下文也並不是乙個高深的概念。

用官話來說限界上下文主要用來封裝通用語言和領域物件。

按我個人的理解它就是用來為領域提供上下文語境,保證在領域之內的一些術語、業務相關物件等(通用語言)有乙個確切的含義,沒有二義性。

DDD理論學習系列(3) 限界上下文

限界上下文可以拆分為兩個詞,限界和上下文。限界 是指乙個界限,具體的某乙個範圍。上下文 個人理解就是語境。比如我們常說的段子 我想靜靜。這個句子一般是想表達 我想靜一靜 的意思。但是我們卻把它玩笑成 靜靜是誰?可見上下文語境很重要。這個例子只是個開胃菜,我們接著往下看。整個應用程式之內的乙個概念性邊...

DDD之領域,子域,限界上下文

從廣義上來講,領域即是乙個組織所做的事情以及其中所包含的一切。一般來講商業機構會確定乙個市場,然後在這個市場中銷售產品和服務。每個組織都有它自己的業務範圍和做事方式,這個業務範圍以及在其中所進行的活動就是領域。由於領域的概念通常都過大,所以我們一般都會將其進行拆分,諸如核心域,通用域,支援域。一般來...

DDD 領域驅動設計中的限界上下文

承接上文,我們知道了,在確定好研究的領域後,我們可以進行粗粒度的拆分,可以將領域拆分成不同的子域,不同的子域又承擔著不同的業務職責,根據重要性,可以將子域分為 核心域 支撐域和通用域,一般來說,我們要將重點放到核心域的開發與整合上。在ddd中,乙個領域被分為若干子域,領域模型是在特定的場景中來設計的...