從廣義上來講，領域即是乙個組織所做的事情以及其中所包含的一切。一般來講商業機構會確定乙個市場，然後在這個市場中銷售產品和服務。每個組織都有它自己的業務範圍和做事方式，這個業務範圍以及在其中所進行的活動就是領域。
由於領域的概念通常都過大，所以我們一般都會將其進行拆分，諸如核心域，通用域，支援域。一般來講核心域就是整個產品的業務價值所在，是乙個組織盈利的根本。或者按照業務來拆分，諸如訂單子域，產品子域，物流子域等。
限界上下文簡單來理解就是物理系統。由於微服務的興起，一般來講乙個子域很有可能就是對應乙個限界上下文。但是在前期業務量不大的情況下，可以採用乙個限界上下文跨越多個子域的方式進行整合。
以乙個產品零售的例子。領域，子域，限界上下文的概念圖如下
這裡我們可以看出電子商務系統橫跨了產品目錄子域，訂單子域，發票子域，物流子域。隨著業務的發展，我們可能需要將其按照子域拆分，拆分成產品系統，發票系統，訂單系統，物流系統。
整合限界上下文有很多種方式，常見的如下
DDD中的領域 子域和限界上下文的說明
領域 領域即是乙個組織所做的事情以及其中所包含的一切。每個組織都有它自己的業務範圍和做事方式。這個業務範圍以及在其中所進行的活動便是領域。當你為某個組織開發軟體時，你面對的便是這個組織的領域。這個領域對你來說應該是清晰的，因為你在此工作。領域既可以表示整個業務系統，也可以表示其中的某個核心域或者支撐...
DDD 領域驅動設計中的限界上下文
承接上文，我們知道了，在確定好研究的領域後，我們可以進行粗粒度的拆分，可以將領域拆分成不同的子域，不同的子域又承擔著不同的業務職責，根據重要性，可以將子域分為 核心域 支撐域和通用域，一般來說，我們要將重點放到核心域的開發與整合上。在ddd中，乙個領域被分為若干子域，領域模型是在特定的場景中來設計的...
DDD之5限界上下文 定義領域邊界的利器
上圖是一張普通地圖，最刺眼的就是邊界？非常好奇地圖繪製工程師是如何描繪如此彎曲多變的邊界的？強制行政區域還是人群歷史原因自然的人以群分？我們再換個視角，對工程師或者架構師來說，微服務的邊界如何劃分呢？基於ddd設計方 中的概念 限界上下文 來劃分微服務的邊界 架構師小李正在團隊推行ddd設計方 領域...