DDD領域驅動實戰(二)-限界上下文(bounded context)

限界上下文定義領域邊界，以確定每個上下文含義在它特定的邊界内都具有唯一含義，領域模型則存于該邊界内。

通用語言

定義

事件風暴過程中，通過團隊交流達成共識的，能夠簡單、清晰、準确描述業務涵義和規則的語言。限界上下文中的通用語言提供了設計領域模型的概念術語。

通用語言是必須通過與領域專家詳細讨論後才得到的統一語言，不管你在團隊承擔什麼角色，在同一領域的軟體生命周期裡都使用統一語言交流。通用語言定義上下文含義，可解決交流障礙，使領域專家和開發人員能夠協作，進而確定業務需求的正确表達。

組成

通用語言包含術語和用例場景，能夠直接反映在代碼。通用語言中的

• 名詞

  給領域對象等概念命名，如商品、訂單，對應實體對象

• 形容詞

  描述這些概念

• 動詞

  表示可完成的操作，比如一個動作或事件，如商品已下單、訂單已付款，對應領域事件或指令

通用語言貫穿DDD。基于它，代碼可讀性更好，最後能将業務需求準确轉化為代碼設計。

1. 事件風暴時，領域專家會和設計、開發人員一起建立領域模型，在領域模組化過程中形成通用的業務術語和使用者故事，這也是一個項目團隊統一語言的過程
2. 通過使用者故事分析會形成一個個領域對象，這些領域對象對應領域模型的業務對象，每一個業務對象和領域對象都有通用的名詞術語，并且一一映射
3. 微服務代碼模型源于領域模型，每個代碼模型的代碼對象跟領域對象一一對應

可以表格記錄事件風暴和微服務設計過程中産生的領域對象及屬性。比如，領域對象在DDD分層架構中的位置、屬性、依賴關系以及與代碼模型對象的映射關系等。

DDD分析和設計過程中的每一個環節都需要保證限界上下文内術語的統一，在代碼模型設計的時侯就要建立領域對象和代碼對象的一一映射，進而保證業務模型和代碼模型的一緻，實作業務語言與代碼語言的統一。

做到這點，就建立了領域對象和代碼對象的映射關系，即可指導開發準确無誤按設計文檔完成微服務開發。即使是不熟悉代碼的業務人員，也可很快找到代碼位置。

限界上下文

限界上下文就是用以确定語義所在的領域邊界。就可在統一的領域邊界内用統一的語言進行交流。

封裝通用語言和領域對象，提供上下文環境，保證在領域之内的一些術語、業務相關對象等（通用語言）無二義性。

這個邊界定義了模型的适用範圍，使團隊所有成員能夠明确地知道什麼應該在模型中實作，不應該在模型中實作。

案例

業務的通用語言也有它的業務邊界。限界上下文就是用來細分領域，進而定義通用語言所在的邊界。

如電商領域的商品，商品在不同階段有不同術語：

• 銷售階段是商品
• 運輸階段則變成貨物

同一個東西，由于業務領域不同，賦予了這些術語不同涵義和職責邊界，這個邊界就可能會成為未來微服務設計的邊界。領域邊界就是通過限界上下文來定義的。

限界上下文和微服務

子域還可根據需要進一步拆分為子子域。如支付子域，繼續拆為收款、付款子子域。拆到一定程度後，有些子子域的領域邊界可能變成限界上下文的邊界了。

子域可能會包含多個限界上下文。

如理賠子域就包括報案、查勘和定損等多個限界上下文（限界上下文與理賠的子子域領域邊界重合）。也有可能子域本身的邊界就是限界上下文邊界，如投保子域。

每個領域模型都有它對應的限界上下文。領域内所有限界上下文的領域模型構成整個領域的領域模型。

理論上限界上下文就是微服務的邊界。我們将限界上下文内的領域模型映射到微服務，就完成了從問題域到軟體的解決方案。

限界上下文是微服務設計和拆分的主要依據。

在領域模型中，如果不考慮技術異構、團隊溝通等因素，一個限界上下文理論上就可以設計為一個微服務。