細心的您可能已經發現了乙個規律，ddd使用了一種由上至下的方式來指導系統的構建。第一層考慮如何把大的領域劃成多個小的子域，重要性不一樣，投入的人和錢肯定也不一樣；第二層考慮系統的架構方面，仍然是一類巨集觀的工作，不過其更加聚焦於如何把大的系統分成幾個物理子系統及子系統間的互動方式（如果非微服務架構，就是要考慮分幾個包或命名空間）；第三層考慮劃小後的子系統自身的架構模式（事件驅動、三層架構、odd架構、事件源架構等）、領域模型（設計模型）等技術細節。這種從上到下的方式約束著我們在看待問題時應當由巨集觀到微觀，更具條理性。好比您認識乙個人，先有乙個整體印象然後才能了解對方的三觀等問題。
我們上一章對子域做了乙個大概的說明，總結起來有四點：1）子域是一種對整體領域的概念上的劃分，是人為的主觀行為；2）子域的目的是把大的領域劃小，使用分而治之的方法來簡化系統建設時的複雜度；3）子域的劃分不是一成不變的；4）領域有界限，不是無限的大。您常聽客戶說「我們有這樣幾塊業務」，一般來說這裡所謂的」幾塊兒「就是指子域。談論子域的時候一般不會涉及過多的技術。假如時間可以倒退50年，那個時候沒有電腦，人們用紙記錄工人的工資。工資管理通過人工的方式來完成，如何管理就是業務規則，是客觀的，和是否有電腦關係不大。
ddd的定義裡，子域包含「核心域」、「支撐域」和「通用域」三類，您經常會迷惑為什麼會這麼定義？怎麼理解不同域的作用？如果我分錯了是不是對系統影響非常大搞不好會失敗？回答您的問題之前我們先看下圖對「子域」是如何定義的。
核心域是指業務中最重要的那部分，是您做這個系統的主要目的。核心域體現了企業的個性，比如「的的」中的「打車」功能，這個業務不存在那「的的」可以說是0價值的。所以核心域相對來說很好確定。如果您是甲方爸爸，不建議使用乙方的人做核心域的研發工作除非乙方是「微軟」、「ibm」這種牛掰公司。
支撐域主要目的是為了支撐核心業務的運轉，關注於業務的某乙個方面。以一般的電商購物系統為例，「客戶中心」用於支撐商品買賣過程，客戶是其中的主體物件；「訊息中心」中於支撐交易過程中的如郵件、簡訊、訊息等功能，這兩類中心既沒有「訂購中心」這種核心域業務那麼重要，也不能隨便找乙個開源的來用，裡面仍然有許多充滿個性化的東西。這一塊可內部人員開發也可以考慮外包來做，必須要做好質量與進度管控。
「核心域」是最關鍵的，「支撐域」和「通用域」相對來說就差了一級，此處的差一級是指資源的投入。
將乙個大的領域劃分成多個小的子域有兩個作用：第一是避免系統混亂，使用分而治之的方式讓您或您的團隊的關注力更加集中。很多時候，系統的需求在一直無限的擴大而您的團隊人數是固定的，先建設哪個後建設哪個得有個先來後到。把業務上分成一塊塊的，排個優先順序，系統開始投入建設後可以讓客戶在最短的時間內看到成果。您做專案為了賺錢，客戶可從中受益；如果客戶是甲方時，局方的負責人看到了東西也好對其上級有個交待，大家相互理解好辦事兒。第二也是最為核心的，不同的業務域可以讓您決定投入的人與錢的數量。比如核心域應該投入最多的錢，能力最好的員工；支撐域相對少一點；通用域不行就花錢買乙個現成的或直接搞開源。
您可能會說：不對，我的系統九成的工作全是核心域的，沒法分。首先想說明的是，乙個優秀的系統不僅僅要包含系統本身，還需要有很多的周邊設施做支撐，是乙個完整的生態，系統越大越是如此，比如日誌匯聚、鏈路追蹤、業務監控等都是生態的一部分。子域的劃分是乙個需要投入精力和思考的工作，您不僅要看眼下還需要再多往前看一步。您也不應該只考慮功能性需求，涉及安全、可用性等問題都應該在規劃之出定義出來，做不做單說，得考慮。「推動技術進步的往往是非功能性需求」。回歸到本文，即使核心域比例很大，也不太可能會涵蓋系統的全面。極端一點，如果真的有95%的核心業務，您還可以對核心域作進一步劃分呢？對劃分出的「核心子域」進行優先順序設定並決策資源投入度，與我們前面的不矛盾。
注意！
1、建議您在專案建設時將「核心域」與「支撐域」等同看待。雖然概念上進行了劃分，但實際落地的時候兩者幾乎是需要同時進行的。劃分的目的其實是讓您在投入資源的時候比如開發人員選擇，支撐域讓中級或一般高階工程師出馬就差不多了，監控運維就可以搞定。
2、「賬戶管理」、「資料字典」這類典型的屬於支撐域的東西，開發工作往往優先於核心域
3、雖然某些域在業務上定義為核心，但系統建設時需要以同核心域相同的資源投入對待。這是靈活的，千萬別陷入教條主義。
子域的劃分是指：確定業務屬於「核心」、「通用」和「支撐」三個域的哪一類；針對每個子域如「核心域」中的內容如何再做細化。
把乙個大的領域分成三個固定子域後，每個子域中的內容就是與您的業務相關的了。需要說明的是業務子域可能會再分為多個部分。比如核心域中包含a、b、c三個業務子域，a的業務子域又可再分成a1、a2兩個業務子子域。細分的標準是每個子域應該有乙個明確的邊界，這個邊界不是以技術作為劃分依據的。比如電商系統中，「銷售中心」是核心子域中的一部分，其內部可再劃分為「商品中心」和「訂單中心」兩個子域。
注意！
在做子域劃分時請使用業務語言而非技術術語，尤其不能說什麼微服務、spring cloud、mysql、kafka等。域屬於業務方面概念，此階段尚未到達討論技術的地步。
根據流程來劃分一般是在功能劃分後的基礎上所做的補充，假如某個業務的進行順序為：a - b - c，三個任務節點亦可以視為三個子域而存在。以電商購物為例，您在按功能分域的時候分割出了乙個訂購子域，訂購的一般流程是：下單、支付、送貨，那麼我們就可以把這個子域再分解為三個子子域：下單子域、支付子域、送貨子域。團隊建設時可能會以此為據組建三個小的專案組。
如果您是乙個ddd初學者，可能會對子域劃分的正確與否產生懷疑。其實沒必要有這一層的顧慮。子域的劃分主觀性很大，經過仔細分析後的劃分基本上也**不離十，隨著後續對業務的深入了解，還會引入新的子域或對現有子域做調整。即使規劃之出有些偏差也並不影響專案的成功失敗，隨時進行調整即可。除非您在規劃之初把很明顯應該作為核心的東西沒有投入足夠的關注，在專案建設前完全沒做過分析工作才可能會出現這類情況。
下一節，講解限界上下文及其與子域的關係。
戲說領域驅動設計（二） 修身
都在it圈子混，為什麼有些人可以成為一流高手，有些人搞了10年研發還只能靠吃老本兒過日子。簡單來說，搞這行兒您得勤奮。特喜歡電影 霸王別姬 中的一句 要想人前顯貴，您就得背後受罪 這人吶，就得學會自已個兒成全自個兒。好多ddd初級玩家上來就特喜歡聊 聚合 啊 框架 啊 事件溯源 啊，劉震雲先生管這個...
戲說領域驅動設計（三） 困境
我第一次捧起老艾那本 領域驅動設計 驚為天人。吾輩上下求索數年，這不正是終極之大道嗎？結果只三天熱乎勁兒，什麼玩意兒 是對這本書的最好評價。好好的一本書讓我 棄之如敝履 差點就 小舟從此逝,江海寄餘生 了。幾年過後讀了網上一些老baby寫的吐槽ddd的文章，幾乎視其為知音啊，那概括的真是精闢，絕對是...
五子棋演算法設計隨想
五子棋演算法設計隨想 五子棋是深受人們特別是年輕朋友喜歡的一種娛樂性很強的益智遊戲。本文講討論如何讓計算機實現具有一定智慧型的五子棋演算法。其中都是隨時所想的記錄。一 如何將乙個空棋位兩端的棋勢累加起來 1 兩端只有一方的棋子 a 衝 衝型 顯然衝 衝還是衝。並且衝值累積。例如，衝1 衝2 衝3。但...