承接上文，我們知道了，在確定好研究的領域後，我們可以進行粗粒度的拆分，可以將領域拆分成不同的子域，不同的子域又承擔著不同的業務職責，根據重要性，可以將子域分為 核心域、支撐域和通用域，一般來說，我們要將重點放到核心域的開發與整合上。
在ddd中，乙個領域被分為若干子域，領域模型是在特定的場景中來設計的，這個場景固定了業務的範圍，固定了一致的語言。
什麼是限界上下文
對應於通用語言，限界上下文是語言的邊界，對於領域模型，限界上下文是模型的邊界，二者對應於問題空間（problem space）的界定。 對於系統的架構，限界上下文還確定了應用邊界和技術邊界，進而幫助我們確定整個系統及各個限界上下文的解決方案。 可以說，限界上下文是連線問題空間與解決方案空間的重要橋梁。這個時候又引申除了兩個詞，也就是問題和解決方案空間，我們來看一下。
問題空間和解決方案空間
領域中同時存在問題空間和解決方案，問題空間中，我們考慮的是業務所面臨的挑戰，在解決方案空間中，我們思考的是如何通過技術來解決這些業務挑戰
根據以上的解釋我們可以認為
限界上下文規定了界限。
這個界限包括語言含義的界限和模型的界限。應用的界限和技術的界限。
限界上下文解決了問題
我們通過乙個或多個限界上下文，裡面包括了聚合、實體、值物件、領域事件、領域服務等，能夠解決實際的業務需求
首先先來一張圖，讓大家對限界上下文有乙個直觀的感受
注：1.限界上下文用實線分隔開
2.子域用虛線分隔開
3.不同的限界上下文用實線進行關聯（上下文對映）
簡單分析
首先這個是乙個抽象的業務領域，這個裡邊包含著子域和限界上下文，abstract的好處就在於，我們可以將已知的或者我們正在涉及到的領域知識進行巢狀。
個人理解
其實困難的地方就在於如何合理的區分子域、核心域、支撐域、通用域，每個公司的業務場景不一樣，分出來的領域模型也會不一樣，難點就在於，我給出任何例子，都僅能代表某一時刻的某一公司的業務場景，完全不具備通用性，所以例子的作用也是幫助大家去理解思想，並不是真正的要深入業務，不要捨本逐末。
例子業務場景：公司 j是做線下生鮮超市的，對於線下超時來說，所有的sku的實時成本**是非常重要的，線下的業務場景比較多，所以我們需要對接wms作為我們的閘道器系統，當庫存發生變動時，來計算實時的sku成本價，也就是倉**。
下面我將倉**系統拆為以下幾個子域和限界上下文。
注：我無法將所有的限界上下文全部列出，只列出了類似於敏捷開發中的mvp。只是為了說明本節討論的問題。
一般來說，乙個子域對應著乙個限界上下文是比較合適的，但是，有些場景下並一定非要這樣不可。
首先，對於核心域來說，一定是我們系統最重要的功能，我們系統就是為了計算成本**，所以計算**的限界上下文一定是屬於核心域。
我們系統承接wms的mq訊息，對於我們系統來說，接誰的訊息不重要，重要的是把訊息轉換為我們倉**系統能夠識別的語言。所以接收訊息進行語言轉換，對我們來說是支撐域。同時，對於spi來說，我們需要rpc或者其他方式來建立與其他系統的資料溝通渠道，獲取一些我們認為重要的值，比如說，我們需要呼叫採購系統的服務，來提供給我們採購價，需要呼叫加工系統，來給我們返回加工的比例等等。所以對我們來說也是支撐域
對於資料的準確性校驗，一致性校驗，傳ebs資料的校驗，這些都需要一定的規則來處理，為的是及時的預警出來，我們需要自己系統實現validate或者使用共用的validate元件，這不重要，重要的是對於我們系統來說，validate是乙個與其他限界上下文都有緊密關係的限界上下文，但此處並不屬於共享核心。只是乙個通用域
結語總之，業務場景不同，拆分的粒度不同，限界上下文是乙個顯式的邊界，領域模型、領域服務、領域事件等就存在於邊界之內，在邊界內，通用語言中的所有術語都有特定含義，可以說，不同限界上下文中可能有同樣的詞彙，但是對於乙個限界上下文內，不存在二義性。希望能夠幫助大家理解好限界上下文
DDD領域驅動設計
公司裡面敏捷專案要講ddd領域驅動設計，加緊學習了一下，找了一些資料研究。eric evans的 domain driven design領域驅動設計 簡稱ddd，evans ddd是一套綜合軟體系統分析和設計的物件導向建模方法，本站jdon.com是國內公開最早討論ddd 之一，可訂閱 ddd專題...
DDD（領域驅動設計）
domain 領域 driven 驅動 design 設計 由eric evans最先提出，目的是對軟體所涉及到的領域進行建模，以應對系統規模過大時引起的軟體複雜性的問題。整個過程大概是這樣 開發團隊和領域專家一起通過 通用語言 ubiquitous language 去理解和消化領域知識，從領域知...
DDD領域驅動設計
極客時間學習筆記 為什麼微服務設計的時候需要ddd？1 軟體架構模式演進的三個階段 第一階段是單機架構 第二階段是集中式架構 第三階段是分布式微服務架構 2 在單機和集中式架構這兩種模式下，軟體無法快速響應需求和業務的迅速變化，最終錯失發展良機。3 微服務拆分困境產生的根本原因就是不知道業務或者微服...