一、域的概念和劃分
DDD對業務領域劃分到一定程度后，便將特定問題限定在了特定的邊界內，這個特定的邊界就是域，在邊界內進行領域建模，微服務代碼落地。

邊界有大有小，領域可以進一步劃分為子域，把問題聚焦到一個特定的業務范圍內。
在領域不斷細分的過程中，通常被分解為核心子域，通用子域和支撐子域
企業內決定核心競爭力的是核心子域里的業務，而沒有個性化訴求，不在業務主流程上的為通用子域，另外一種不是企業核心競爭力能力的，但對于核心子域的建設是不可缺少的稱為支撐子域，支撐子域和通用子域都可以被多個核心子域重復使用。
比如電商領域中，營銷，推薦，購物，直播是他的核心子域，而這些核心業務邏輯都需要訂單，支付，用戶信息，所以這部分為通用子域，而支撐子域更多為公共服務的實現，如任何子域都需要使用到的數據字典，國際化，權限認證等。

二、核心子域的選擇
比如人作為一個領域的話，身高，體重，背景，外貌，性格，品行是子域，那么對于不同的人來說，核心子域是可以不同的，外貌協會會把外貌作為核心子域，拜金的會把背景作為核心子域。
在同一個領域，不同核心領域的選擇，決定了一個企業的戰略方向和商業模式，例如電商領域里，淘寶是C2C，京東是B2C，戰略方向和商業模式最終會導致核心領域選擇的不同，導致企業的核心投入占比不同。
所以核心子域的建模，要排在領域建模的首要位置，他會決定企業的投資方向和戰略地位。

三、限界上下文（Bounded Context）
限界上下文定義了領域模型的邊界和業務適用范圍，使得團隊所有成員明確什么內容應該在領域模型中實現，什么東西不應該出現
定義限界上下文通常考慮領域業務職責單一的因素，確定了職責邊界后，將所有實現該領域職能相關的對象都放在同一個限界上下文邊界內，而將所有與該職能無關的對象排除在上下文邊界之外，限界上下文就是一個強制邊界，保證領域職責的單一性。
部門的組織架構劃分，實際就是定義部門的限界上下文，企業設置組織架構時，通常從部門職責出發，設立人力資源部，行政部，技術部，銷售部，咨詢部，部門的只能邊界就是企業這個領域的上下文邊界。在部門內聚集和部門相關技能的成員，職責。部門邊界的區分是為了避免不相干的成員散落在各個部門，給人造成一種組織架構混亂的感覺，覺得這個企業的組織架構不夠單一，界限明確，不能夠專業的人干專業的事。
限界上下文本質上就是子域。當一個領域，我們劃分的子域足夠小的時候，就可以在子域內劃分限界上下文，進行領域建模了，如果子域劃分得足夠小不可再拆分，那么限界上下文剛好和子域的邊界一致，如果子域還能再次劃分，一個子域內出現多個限界上下文，也是OK的

四、共同語言
三百六十行，行行出狀元。在上文的部門職能上下文內，不同部門內的行話也是不一樣的，比如技術部用技術相關的語言交流，人力資源部用人力相關的語言交流，這些共同語言組成了部門間的語言上下文邊界
比如電商領域的淘寶，商品在進貨階段叫貨物，銷售階段叫寶貝，快遞階段叫快遞，一件東西在不同的階段會有不同的表現形式，由于業務領域邊界的不同，需要達成對領域內對象，實體的共同語言描述，避免造成歧義。

　 參考書籍 ——《基于DDD和微服務的中臺架構與實現》歐創新、鄧頔
　 參考書籍 ——《領域驅動設計》Eric Evans
　 參考書籍 ——《架構真經》Martin L. Abbott

總結

以上是生活随笔為你收集整理的DDD—子域和限界上下文的全部內容，希望文章能夠幫你解決所遇到的問題。

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