DDD中的領域 子域和限界上下文的說明

領域

領域既可以表示整個業務系統，也可以表示其中的某個核心域或者支撐子域。

工作中的子域和限界上下文

（上圖中我們可以找出多個隱式的領域模型，它們沒有很好的被分離出來）

通過ddd戰略設計工具，可以按照實際功能將這些交織的模型劃分成邏輯上相互分離的子域，在一定程度上減少系統的複雜性。

原文中的乙個joke

lb:"有護欄隔離時，我和令居相處的很好，護欄壞了以後，情況就變了。"

aj:"對的，你需要將你的護欄造成和馬一樣高"

如下，示例乙個抽象的業務領域

核心域：它是整個業務領域的一部分，也是業務功能的主要促成因素。在戰略層面上講，企業應該在核心域上勝人一籌，給予最高的優先順序、最資深的領域專家和最優秀的開發團隊。

支撐子域：有時會建立或者購買某個限界上下文來支撐我們的業務。如果這樣的限界上下文應對著業務的某些重要方面，但卻不是核心，那麼它便是乙個支撐子域。它專注於業務的某個方面。

通用子域：乙個子域被用於整個業務系統，整個子域別是通用子域。

支撐子域和通用子域並不是不重要，只是對他們的要求並不想核心域那麼高。

限界上下文：主要是語言層面上的限界劃分，是實現ddd的關鍵。乙個限界上下文並不一定只包含在乙個子域中。限的意思就是劃分、規定，界就是界限、或者乙個邊界，上下文就是業務的整個流程。限界上下文定義了領域模型的邊界，目的是清理子域，然後區分子域哪些是核心域、支撐子域和通用子域

戰略設計為什麼重要

很多開發者將關注點放在了實體和值物件上，從而缺少了廣闊ide視野。將不同的核心概念雜揉在一起，導致他們將兩個模型構成了乙個。如下所示：

(不了解基本的戰略設計，導致在協作模型中產生了不相匹配的概念，虛線是問題所在)

q：是不是因為使用者(user)和許可權(permission)與協作概念存在著緊密的耦合？

a：資深開發指出：問題不單單在於耦合，到最後，論壇、討論、日曆和日曆條目都會在一定程度上與協作人員發生耦合，這是事實。問題出在我們使用的語言，問題在於論壇和討論等概念與錯誤的語言概念耦合起來了。使用者和許可權與協作活動沒有任何關係，並且與協作的通用語言也風牛馬不相及。使用者和許可權是與身份(identity)和訪問(access)相關概念，即是與安全(security)相關的。在協作上下文**現的每一種概念都必須與協作存在語言層面上的關聯。而上圖中沒有。

通過增加角色這一協作上下文可以明確業務指向。

如何命名限界上下文?

上文中用到的『協作上下文』是通過「模型 + 上下文」這種方式來命名限界上下文的。表明它是包含有協作領域物件的限界上下文。

現實世界中的領域和子域

領域中還同時存在問題空間和解決方案空間

問題空間

我們思考的是業務所面臨的挑戰。對問題空間的開發將產生乙個新的核心域。對問題空間的評估應該同時考慮已有子域和額外所需子域。因此，問題空間是核心域和其他子域的組合。問題空間中的子域常常隨著專案的不同而不同，他們各自關注當前的業務問題。

解決方案空間

思考如何實現軟體以解決這些業務挑戰。包含乙個或多個限界上下文，即一組特定的軟體模型。這是因為限界上下文即是乙個特定的解決方案。它通過軟體的方式來實現解決方案。

對於問題空間的評估是有益於理解解決方案空間的。解決方案空間在很大程度上受到現有系統和技術的影響。

下圖是乙個erp系統的領域模型(只顯示了特定問題空間的子域，並不是整個領域)

我們應該根據分離的限界上下文仔細地思考一下問題：

記住，開發核心域的解決方案是一種關鍵性的業務投入。

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

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

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

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

DDD之5限界上下文 定義領域邊界的利器

上圖是一張普通地圖，最刺眼的就是邊界？非常好奇地圖繪製工程師是如何描繪如此彎曲多變的邊界的？強制行政區域還是人群歷史原因自然的人以群分？我們再換個視角，對工程師或者架構師來說，微服務的邊界如何劃分呢？基於ddd設計方 中的概念 限界上下文 來劃分微服務的邊界 架構師小李正在團隊推行ddd設計方 領域...