老李一直懷疑自己是不是年紀大了，腦子跟不上了。

作為十幾年經(jīng)驗的資深 Java 工程師，維護這公司產(chǎn)品的核心代碼的他，現(xiàn)在迭代產(chǎn)品的時候，經(jīng)常出 Bug 。

有時修復一個 Bug 時間，比開發(fā)一個需求的時間要長很多，這是常有的事兒，更可怕的是，改完一個 Bug ，又多出來幾個 Bug，讓人吐血不止。

這樣的情況不在少數(shù)，近幾次的更新都沒有按原計劃的時間完成，不但讓 Leader 對老李的能力產(chǎn)生懷疑，也讓他自己開始懷疑自己。

這是產(chǎn)品迭代到一定時期，必然出現(xiàn)的問題；還是自己年紀大了，在開發(fā)時各種問題沒有考慮周全，多年的開發(fā)經(jīng)驗都不能支撐新的需求。

中年危機加上職業(yè)瓶頸，老王覺得自己應該回家修整一下狀態(tài)了......

廢話，改 Bug 的痛苦，每個人都經(jīng)歷過…...

改不完的 Bug，是「思想錯誤」

我們可以發(fā)現(xiàn)領域驅(qū)動設計的一大優(yōu)點：系統(tǒng)高度模塊化，代碼重用度高，不會出現(xiàn)太多的重復邏輯。

從戰(zhàn)略到戰(zhàn)術(shù)，領域驅(qū)動設計（Domain Driven Design，DDD）給出了諸多關(guān)于軟件架構(gòu)、設計、建模與編碼的方法和模式，以用于應對業(yè)務復雜度。

對于學習 DDD 的開發(fā)人員而言，第一重要的不是掌握 DDD 的模式，而是要改變分析思維與設計思維的方式。將這種思維方式運用到軟件項目開發(fā)過程中，就是我所提到的「領域模型驅(qū)動設計」，它的核心內(nèi)容可以通過層層推進的形式匯集為如下三句話：

• 以領域為分析建模的驅(qū)動力

• 以場景為設計建模的驅(qū)動力

• 以任務為實現(xiàn)建模的驅(qū)動力

如何理解這三句話？

當你開始領域模型驅(qū)動設計時，必須在分析建模階段拋開實現(xiàn)技術(shù)對你的影響，與需求分析人員、測試人員一起單純針對「領域」進行分析建模，即提煉與抽象領域概念，并以統(tǒng)一語言和模型的形式來表達。

在設計建模階段，圍繞著一個完整的「場景」開展設計工作。需求分析人員為「場景」編寫用戶故事；測試人員為「場景」編寫驗收標準；開發(fā)人員則開始解剖「場景」，將其分解為組合任務與原子任務，然后各自分配給不同的角色構(gòu)造型。

到了實現(xiàn)建模階段，就針對這些任務定義測試用例，開始測試驅(qū)動開發(fā)，由內(nèi)至外到達應用服務時，再將它們集成起來。顯然，領域模型驅(qū)動設計就是針對領域開展的「合而分分而合」的解構(gòu)過程。

同時，必須謹記：領域模型驅(qū)動設計的基礎是限界上下文。在領域驅(qū)動設計的戰(zhàn)略階段，同樣是一個「合而分分而合」的解構(gòu)過程：將領域分解為限界上下文，再通過上下文映射聯(lián)合限界上下文共同實現(xiàn)多個領域場景。

以上內(nèi)容正是我言猶未盡想要表達的精髓。學習領域驅(qū)動設計，就需要抓住 DDD 的根本和精髓。你需要理解什么是限界上下文，它帶來的價值是什么；你需要理解如何進行領域建模，統(tǒng)一語言在其中扮演了什么樣的角色；你需要理解為何領域驅(qū)動設計提倡以領域為驅(qū)動力，為何需要領域?qū)＜覅⑴c到項目開發(fā)中來。

提升了對這些內(nèi)容的認識后，再去學習 DDD 給出的設計模式，學習我給出的固化設計過程，如場景驅(qū)動設計。然后找三兩個不曾實施 DDD 的項目，尋兩三個實施了 DDD 的項目，相互對比其模型與代碼，你絕對會有一種醍醐灌頂?shù)母杏X。當然，這些都需要你沉下心來細心體會，認真思考，還需要你廣泛涉獵更多軟件設計與開發(fā)的知識，如此方能打通 DDD 的任督二脈。

DDD 不是一門容易衰亡的軟件方法學，反而越來越被行業(yè)所認可，薪資待遇也是水漲船高超過了大部分平均值。我從 2017 年 11 月寫下本專欄的第一個字到現(xiàn)在完成整個專欄，已有兩年多的時間了，好在 DDD 在這兩年后依然算是一門顯學，在微服務與中臺光芒的映襯下，DDD 也變得越來越耀眼。

如今，專欄終于完成了！《戰(zhàn)略篇》一共 34 章，15 萬 5 千字；《戰(zhàn)術(shù)篇》一共 71 章，35 萬 1 千字；合計 105 章，共 50 萬 6 千余字，加上兩篇開篇詞與這篇可以稱為寫后感的后記，共 108 章，算是湊齊了一百單八將。如此成果也足可慰藉我為之付出的兩年多艱辛時光！