細心的您可能已經發現了一個規律，DDD使用了一種由上至下的方式來指導系統的構建。第一層考慮如何把大的領域劃成多個小的子域，重要性不一樣，投入的人和錢肯定也不一樣；第二層考慮系統的架構方面，仍然是一類巨集觀的工作，不過其更加聚焦於如何把大的系統分成幾個物理子系統及子系統間的互動方式（如果非微服務架構，就是要考慮分幾個包或名稱空間）；第三層考慮劃小後的子系統自身的架構模式（事件驅動、三層架構、ODD架構、事件源架構等）、領域模型（設計模型）等技術細節。這種從上到下的方式約束著我們在看待問題時應當由巨集觀到微觀，更具條理性。好比您認識一個人，先有一個整體印象然後才能瞭解對方的三觀等問題。
我們上一章對子域做了一個大概的說明，總結起來有四點：1）子域是一種對整體領域的概念上的劃分，是人為的主觀行為；2）子域的目的是把大的領域劃小，使用分而治之的方法來簡化系統建設時的複雜度；3）子域的劃分不是一成不變的；4）領域有界限，不是無限的大。您常聽客戶說“我們有這樣幾塊業務”，一般來說這裡所謂的”幾塊兒“就是指子域。談論子域的時候一般不會涉及過多的技術。假如時間可以倒退50年，那個時候沒有電腦，人們用紙記錄工人的工資。工資管理通過人工的方式來完成，如何管理就是業務規則，是客觀的，和是否有電腦關係不大。
1、子域分類
DDD的定義裡，子域包含“核心域”、“支撐域”和“通用域”三類，您經常會迷惑為什麼會這麼定義？怎麼理解不同域的作用？如果我分錯了是不是對系統影響非常大搞不好會失敗？回答您的問題之前我們先看下圖對“子域”是如何定義的。
核心域是指業務中最重要的那部分，是您做這個系統的主要目的。核心域體現了企業的個性，比如“的的”中的“叫車”功能，這個業務不存在那“的的”可以說是0價值的。所以核心域相對來說很好確定。如果您是甲方爸爸，不建議使用乙方的人做核心域的研發工作除非乙方是“微軟”、“IBM”這種牛掰公司。
支撐域主要目的是為了支撐核心業務的運轉，關注於業務的某一個方面。以一般的電商購物系統為例，“客戶中心”用於支撐商品買賣過程，客戶是其中的主體物件；“訊息中心”中於支撐交易過程中的如郵件、簡訊、訊息等功能，這兩類中心既沒有“訂購中心”這種核心域業務那麼重要，也不能隨便找一個開源的來用，裡面仍然有許多充滿個性化的東西。這一塊可內部人員開發也可以考慮外包來做，必須要做好質量與進度管控。
通用域的概念相對而言就比較模糊了：有說“如果子域被用於整個業務系統，這個子域就是通用域。比如保險業務，其核心是‘投保’、‘生成保單’等，電商化後為了讓使用者在各類渠道如APP、網站、微信小程式等進行各類保險（車險、養老、財產等）的受理而引入了‘訂單中心’，這裡的‘訂單中心’就是通用域，因為他通用於各類渠道和各類保險銷售場景”，有點支撐域的味道；有說“通用域用於起到增強的作用，比如我們看視訊網站時通常會有的‘收藏’功能”；本文對於這個概念的解釋是：通用域的東西一般是有現成的解決方案，可直接購買或下載開源。以此作為解釋也是為了對應我們所強調的子域對於資源投入的指導性。
“核心域”是最關鍵的，“支撐域”和“通用域”相對來說就差了一級，此處的差一級是指資源的投入。
將一個大的領域劃分成多個小的子域有兩個作用：第一是避免系統混亂，使用分而治之的方式讓您或您的團隊的關注力更加集中。很多時候，系統的需求在一直無限的擴大而您的團隊人數是固定的，先建設哪個後建設哪個得有個先來後到。把業務上分成一塊塊的，排個優先順序，系統開始投入建設後可以讓客戶在最短的時間內看到成果。您做專案為了賺錢，客戶可從中受益；如果客戶是甲方時，局方的負責人看到了東西也好對其上級有個交待，大家相互理解好辦事兒。第二也是最為核心的，不同的業務域可以讓您決定投入的人與錢的數量。比如核心域應該投入最多的錢，能力最好的員工；支撐域相對少一點；通用域不行就花錢買一個現成的或直接搞開源。
您可能會說：不對，我的系統九成的工作全是核心域的，沒法分。首先想說明的是，一個優秀的系統不僅僅要包含系統本身，還需要有很多的周邊設施做支撐，是一個完整的生態，系統越大越是如此，比如日誌匯聚、鏈路追蹤、業務監控等都是生態的一部分。子域的劃分是一個需要投入精力和思考的工作，您不僅要看眼下還需要再多往前看一步。您也不應該只考慮功能性需求，涉及安全、可用性等問題都應該在規劃之出定義出來，做不做單說，得考慮。“推動技術進步的往往是非功能性需求”。迴歸到本文，即使核心域比例很大，也不太可能會涵蓋系統的全面。極端一點，如果真的有95%的核心業務，您還可以對核心域作進一步劃分呢？對劃分出的“核心子域”進行優先順序設定並決策資源投入度，與我們前面的不矛盾。
|
注意！ 1、建議您在專案建設時將“核心域”與“支撐域”等同看待。雖然概念上進行了劃分，但實際落地的時候兩者幾乎是需要同時進行的。劃分的目的其實是讓您在投入資源的時候比如開發人員選擇，支撐域讓中級或一般高階工程師出馬就差不多了，監控運維就可以搞定。 2、“賬戶管理”、“資料字典”這類典型的屬於支撐域的東西，開發工作往往優先於核心域 3、雖然某些域在業務上定義為核心，但系統建設時需要以同核心域相同的資源投入對待。這是靈活的，千萬別陷入教條主義。 |
2、子域劃分方法
子域的劃分是指：確定業務屬於“核心”、“通用”和“支撐”三個域的哪一類；針對每個子域如“核心域”中的內容如何再做細化。
把一個大的領域分成三個固定子域後，每個子域中的內容就是與您的業務相關的了。需要說明的是業務子域可能會再分為多個部分。比如核心域中包含A、B、C三個業務子域，A的業務子域又可再分成A1、A2兩個業務子子域。細分的標準是每個子域應該有一個明確的邊界，這個邊界不是以技術作為劃分依據的。比如電商系統中，“銷售中心”是核心子域中的一部分，其內部可再劃分為“商品中心”和“訂單中心”兩個子域。
業務子域的劃分一般來說可以從兩個維度出發：功能與流程。通過功能劃分其實是可以根據感覺走的，雖然很不嚴肅，但也不是什麼很玄的東西。有些業務聽起來看起來就可區分其重要性。比如做個論壇，監控非常重要，但您不會真的投入一半人馬去開發個主機監控系統吧？比如您熟悉的“豆瓣網”，“讀書頻道”與“電影頻道”肯定得作為核心域中的兩個業務子域吧？這種下意識的分割有時候很準，人是有這個靈性的。根據功能來分域一般是劃分子域的一個非常非常重要的參考，下面我們以個人微信為例嘗試通過功能的維度進行子域劃分。
|
注意！ 在做子域劃分時請使用業務語言而非技術術語，尤其不能說什麼微服務、Spring Cloud、MySQL、Kafka等。域屬於業務方面概念，此階段尚未到達討論技術的地步。 |
下圖為個人微信子域的示意圖，也許與您設想的有不一致的情況，此處有很強的主觀性。試想一下，這樣的一個圖如果可以在設計之初定義下來，基本上您和您的團隊以及客戶就可以在巨集觀上大概知道了這個系統要做什麼，有哪些主要的業務。此圖除用於資源分配的決策，還能在後續設計限界上下文時給予指導。
根據流程來劃分一般是在功能劃分後的基礎上所做的補充，假如某個業務的進行順序為：A - B - C，三個任務節點亦可以視為三個子域而存在。以電商購物為例，您在按功能分域的時候分割出了一個訂購子域，訂購的一般流程是：下單、支付、送貨，那麼我們就可以把這個子域再分解為三個子子域：下單子域、支付子域、送貨子域。團隊建設時可能會以此為據組建三個小的專案組。
如果您是一個DDD初學者，可能會對子域劃分的正確與否產生懷疑。其實沒必要有這一層的顧慮。子域的劃分主觀性很大，經過仔細分析後的劃分基本上也八九不離十，隨著後續對業務的深入瞭解，還會引入新的子域或對現有子域做調整。即使規劃之出有些偏差也並不影響專案的成功失敗，隨時進行調整即可。除非您在規劃之初把很明顯應該作為核心的東西沒有投入足夠的關注，在專案建設前完全沒做過分析工作才可能會出現這類情況。
下一節，講解限界上下文及其與子域的關係。