老李一直懷疑自己是不是年紀大了，腦子跟不上了。
作為十幾年經驗的資深 Java 工程師，維護這公司產品的核心代碼的他，現在疊代產品的時候，經常出 Bug 。
有時修復一個 Bug 時間，比開發一個需求的時間要長很多，這是常有的事兒，更可怕的是，改完一個 Bug ，又多出來幾個 Bug，讓人吐血不止。
這樣的情況不在少數，近幾次的更新都沒有按原計劃的時間完成，不但讓 Leader 對老李的能力產生懷疑，也讓他自己開始懷疑自己。
這是產品疊代到一定時期，必然出現的問題；還是自己年紀大了，在開發時各種問題沒有考慮周全，多年的開發經驗都不能支撐新的需求。
中年危機加上職業瓶頸，老王覺得自己應該回家修整一下狀態了......
廢話，改 Bug 的痛苦，每個人都經歷過…...
不管是系統維護，還是是在現有系統中進行疊代開發的老司機們，這種痛苦經歷，想必你們很熟悉吧：
當需要修改一個 Bug 的時候，面對一個類中成百上千行的代碼，沒有注釋，千奇百怪的方法和變量名字，層層嵌套的方法調用，混亂不堪的結構，不要說準確找到 Bug 所在的位置，就是要清晰知道一段代碼究竟是做了什麼也非常困難，最終，改對了一個 Bug，卻多冒出 N 個新 Bug；
同樣的情況，當你拿到一份新的需求，需要在現有系統中添加功能的時候，面對一行行完全過程式的代碼，需要使用一個功能時，不知道是應該自己編寫，還是應該尋找是否已經存在的方法。
編寫一個非常簡單的新、刪、改功能，卻要費盡九牛二虎之力，最終發現，系統存在著太多的重複邏輯，閱讀、測試、修改非常困難。
在經歷了這些痛苦之後，我們都會發出一個感慨：MDZZ，與其進行系統維護和疊代開發，還不如重新設計開發一個新的系統來得痛快……
改不完的 Bug，是「思想錯誤」
當你遇到，你應該怎樣解決？
面對這一系列讓軟體陷入無底泥潭的問題，基於面向對象思想的領域驅動設計方法是一個很好的解決方法。
從事過系統設計的富有經驗的設計師們，對職責單一原則、信息專家、充血/貧血模型、模型驅動設計這些名詞或概念應該不會感到陌生。
我們可以發現領域驅動設計的一大優點：系統高度模塊化，代碼重用度高，不會出現太多的重複邏輯。
從戰略到戰術，領域驅動設計（Domain Driven Design，DDD）給出了諸多關於軟體架構、設計、建模與編碼的方法和模式，以用於應對業務複雜度。
對於學習 DDD 的開發人員而言，第一重要的不是掌握 DDD 的模式，而是要改變分析思維與設計思維的方式。將這種思維方式運用到軟體項目開發過程中，就是我所提到的「領域模型驅動設計」，它的核心內容可以通過層層推進的形式匯集為如下三句話：
-
以領域為分析建模的驅動力
-
以場景為設計建模的驅動力
-
以任務為實現建模的驅動力
如何理解這三句話？
當你開始領域模型驅動設計時，必須在分析建模階段拋開實現技術對你的影響，與需求分析人員、測試人員一起單純針對「領域」進行分析建模，即提煉與抽象領域概念，並以統一語言和模型的形式來表達。
在設計建模階段，圍繞著一個完整的「場景」開展設計工作。需求分析人員為「場景」編寫用戶故事；測試人員為「場景」編寫驗收標準；開發人員則開始解剖「場景」，將其分解為組合任務與原子任務，然後各自分配給不同的角色構造型。
到了實現建模階段，就針對這些任務定義測試用例，開始測試驅動開發，由內至外到達應用服務時，再將它們集成起來。顯然，領域模型驅動設計就是針對領域開展的「合而分分而合」的解構過程。
同時，必須謹記：領域模型驅動設計的基礎是限界上下文。在領域驅動設計的戰略階段，同樣是一個「合而分分而合」的解構過程：將領域分解為限界上下文，再通過上下文映射聯合限界上下文共同實現多個領域場景。
以上內容正是我言猶未盡想要表達的精髓。學習領域驅動設計，就需要抓住 DDD 的根本和精髓。你需要理解什麼是限界上下文，它帶來的價值是什麼；你需要理解如何進行領域建模，統一語言在其中扮演了什麼樣的角色；你需要理解為何領域驅動設計提倡以領域為驅動力，為何需要領域專家參與到項目開發中來。
提升了對這些內容的認識後，再去學習 DDD 給出的設計模式，學習我給出的固化設計過程，如場景驅動設計。然後找三兩個不曾實施 DDD 的項目，尋兩三個實施了 DDD 的項目，相互對比其模型與代碼，你絕對會有一種醍醐灌頂的感覺。當然，這些都需要你沉下心來細心體會，認真思考，還需要你廣泛涉獵更多軟體設計與開發的知識，如此方能打通 DDD 的任督二脈。
DDD 不是一門容易衰亡的軟體方法學，反而越來越被行業所認可，薪資待遇也是水漲船高超過了大部分平均值。我從 2017 年 11 月寫下本專欄的第一個字到現在完成整個專欄，已有兩年多的時間了，好在 DDD 在這兩年後依然算是一門顯學，在微服務與中台光芒的映襯下，DDD 也變得越來越耀眼。
這一路走來，讀者們給了我莫大的鼓勵。作為全網首個DDD 專欄，已有超過5000 位同學訂閱學習了。大家每天都在群里進行各種交流分享，畢竟自己悶頭學不如群策群力，一起給出解決方案更高效。
如今，專欄終於完成了！《戰略篇》一共 34 章，15 萬 5 千字；《戰術篇》一共 71 章，35 萬 1 千字；合計 105 章，共 50 萬 6 千餘字，加上兩篇開篇詞與這篇可以稱為寫後感的後記，共 108 章，算是湊齊了一百單八將。如此成果也足可慰藉我為之付出的兩年多艱辛時光！
如果你想從此寫代碼再也碰不到 Bug
↓↓↓這門專欄非常適合你！↓↓↓
限時特價中
原價 168 元，限時立享 7 折！↓下單再送 7 門萬人訂閱的編程課↓118 元 = 108 章專欄➕7 門贈送編程課➕1V1 答疑➕源碼（迄今為止最划算的訂閱時間）
現在訂閱你能獲得什麼？
1. 專業老師陪伴式教學
張逸：曾就職於中興、惠普、中軟國際等公司的高級軟體工程師
張逸老師將全程陪你一起吃透每章節內容，不再是你一人悶頭去深究那些看不懂的知識點，讓你能更高效快速的將所學的內容運用到工作項目中，讓你的領導同事大吃一驚。
2. 360度全方位答疑服務
每個專欄都配有多個答疑交流群便於你們提問，老師幾乎全程在線解答。群內還會有小助手負責日常整潔，讓你在交流學習的同時不受到外界干擾。
3. 額外的福利
你不僅能以 7 折的優惠價格擁有戰術➕戰略 2 門合訂版專欄，現在下單還將免費得到7門編程專欄。
如果你想從此寫代碼再也碰不到 Bug
↓↓↓這門專欄非常適合你！↓↓↓
限時特價中
原價 168 元，限時立享 7 折！↓下單再送 7 門萬人訂閱的編程課↓118 元 = 108 章專欄➕7 門贈送編程課➕1V1 答疑➕源碼（迄今為止最划算的訂閱時間）
訂閱須知
本專欄可在 GitChat 服務號、App 及網頁端上多端閱讀。
本專欄為圖文內容，總共 108 篇課時。
本專欄一經購買，即可享受永久閱讀權限。