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

通用語言

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

通用語言不是平白產生的，它必須通過與領域專家詳細討論之后才能得到的統一語言，不管你在團隊中承擔什么角色，在同一領域的軟件生命周期里都使用統一的語言進行交流。通用語言定義上下文含義，它可解決交流障礙，使領域專家和開發人員能夠協作，從而確保業務需求的正確表達。

通用語言包含術語和用例場景，能夠直接反映在代碼。通用語言中的 - 名詞，用于給領域對象等概念命名，如商品、訂單，對應實體對象 - 形容詞，用于描述這些概念 - 動詞，表示可以完成的操作，比如一個動作或事件，如商品已下單、訂單已付款，對應領域事件或者命令

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

• 從事件風暴建立通用語言到領域對象設計和代碼落地過程

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

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

下面是一個微服務設計實例的部分數據，表格中的這些名詞術語就是項目團隊在事件風暴過程中達成一致、可用于團隊內部交流的通用語言。

DDD分析過程中所有的領域對象及它們的屬性都被記錄，除了領域對象，還記錄了在微服務設計過程中領域對象所對應的代碼對象，并一一映射。

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

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

限界上下文

語言都有語義環境，通用語言亦是。為避免同樣概念或語義在不同上下文環境中歧義，DDD在提出“限界上下文”，確定語義所在的領域邊界。就可在統一的領域邊界內用統一的語言進行交流。

就是封裝通用語言和領域對象，提供上下文環境，保證在領域之內的一些術語、業務相關對象等（通用語言）有一個確切的含義，沒有二義性。 這個邊界定義了模型的適用范圍，使團隊所有成員能夠明確地知道什么應該在模型中實現，不應該在模型中實現。

案例

都說漢語博大精深，不同的情境下，一個詞會有不同涵義。比如小孩問媽媽：“今天應該穿幾件衣服呀？”媽媽說：“能穿多少就穿多少！”那到底是穿多還是穿少？沒有具體語境，還真不好判斷。但若限定語境，比如寒冬或炎夏，就很清晰了。所以語言離不開它的語義環境。

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

如電商領域的商品，商品在不同階段有不同術語，在銷售階段是商品，而在運輸階段 則變成貨物。同一個東西，由于業務領域不同，賦予了這些術語不同涵義和職責邊界，這個邊界就可能會成為未來微服務設計的邊界。領域邊界就是通過限界上下文來定義的。

限界上下文和微服務

車險承保的流程包含了投保、繳費、出單等幾個主要流程。如果出險了還會有報案、查勘、定損、理算等理賠流程。 保險領域被拆分為：投保、支付、保單管理和理賠四個子域。子域還可根據需要進一步拆分為子子域，比如，支付子域可繼續拆分為收款和付款子子域。拆到一定程度后，有些子子域的領域邊界就可能變成限界上下文的邊界了。子域可能會包含多個限界上下文，如理賠子域就包括報案、查勘和定損等多個限界上下文（限界上下文與理賠的子子域領域邊界重合）。也有可能子域本身的邊界就是限界上下文邊界，如投保子域。 每個領域模型都有它對應的限界上下文，團隊在限界上下文內用通用語言交流。領域內所有限界上下文的領域模型構成整個領域的領域模型。理論上限界上下文就是微服務的邊界。我們將限界上下文內的領域模型映射到微服務，就完成了從問題域到軟件的解決方案。 限界上下文是微服務設計和拆分的主要依據。在領域模型中，如果不考慮技術異構、團隊溝通等其它外部因素，一個限界上下文理論上就可以設計為一個微服務。 不過微服務的拆分還是有很多限制因素的，在設計中不宜過度拆分

總結

通用語言確定了項目團隊內部交流的統一語言，而這個語言所在的語義環境則是由限界上下文來限定的，以確保語義的唯一性。 領域專家、架構師和開發人員的主要工作就是通過事件風暴來劃分限界上下文。限界上下文確定了微服務的設計和拆分方向，是微服務設計和拆分的主要依據。如果不考慮技術異構、團隊溝通等其它外部因素，一個限界上下文理論上就可以設計為一個微服務。

參考 - 限界上下文：定義領域邊界的利器

總結

以上是生活随笔為你收集整理的商品领域ddd_DDD领域驱动实战 - 限界上下文（bounded context）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。