版權(quán)聲明：本作品采用【知識共享署名-非商業(yè)性使用-禁止演繹 4.0 國際許可協(xié)議】進行許可。

前言

在這一年聚焦DDD設計，尤其是DDD的協(xié)作設計工作坊的咨詢工作中，我發(fā)現(xiàn)客戶同很多咨詢顧問之間總是存在以下沖突：

• 體驗的“一致性”沖突
  • 客戶：希望不同的顧問在售賣方法論的時候解釋能一致；
  • 顧問：認為每個人對方法論的認識和理解本身就不同，很難做到一致。
• 服務的“標準化”沖突
  • 客戶：希望顧問能夠?qū)⑺圪u的方法論進行標準化；
  • 顧問：認為顧問所售賣的方法論本身非常靈活，需要 By Experience 依據(jù)不同的情況進行適配，標準化是做不到，并且也是不應該做的。

結(jié)合我曾經(jīng)在ThoughtWorks近4年的人員培養(yǎng)和教學經(jīng)驗，和這幾年來的咨詢經(jīng)驗，我能夠理解客戶這樣要求，是因為希望能夠?qū)崿F(xiàn)方法論的規(guī)?；涞?。而在方法論規(guī)?；涞氐倪^程中，一個很重要的問題，就是絕大多數(shù)能力一般的人，都更習慣于依據(jù)“明確的指令”進行工作，而不是依賴自己“有限的經(jīng)驗”和“莫能兩可的方法論”。

這篇文章就是記錄我是如何來解決這個問題的。

我的基準化思維框架

對DDD這樣的方法論進行“按部就班”式的基準化梳理，從而形成“基準化的操作”，以提供“明確的指令”，說起來簡單，做起來卻沒有想象中容易。絕大多數(shù)的顧問雖然能夠?qū)Ψ椒ㄕ撨M行階段性拆分，但是卻沒有能夠?qū)⒎椒ㄕ撨M行細粒度的拆分和驗證。

從我的觀察來看，之所以造成這個問題，主要原因來自幾個方面：

• 對方法論的深入研究不夠：在售賣方法論的時候，現(xiàn)學現(xiàn)賣。
• 缺乏反復的思考和打磨：缺乏機會進行反復驗證和優(yōu)化，或者注意力不夠聚焦。

還有一個很重要的原因，就是絕大多數(shù)技術(shù)顧問可能脫離寫代碼這件事情太久了，沒有意識到對方法論基準化非常像我們開發(fā)軟件的過程：

• 首先，都是需要從客戶需要出發(fā)，明確交付目標的價值和內(nèi)容。
• 然后，以Tasking思想和階段性驗收條件為著眼點，將目標拆解為不同的階段。
• 接下來，對每個階段進行細化的實現(xiàn)，保證每個階段的驗收條件在實現(xiàn)過程中可以通過最簡單的方式達成。
• 最后，產(chǎn)出第一版最小基準化內(nèi)容，通過不斷的適配和打磨，進行迭代式的改進，或者較大幅度的修改（類似需求變更）。

更重要的是，以上這個過程，是可以用“測試驅(qū)動開發(fā)（Test Driven Development）”的思想來做的！

利用TDD的方式進行DDD設計過程的基準化

那么，我是怎樣用TDD的思想，對DDD的設計過程進行基準化的呢？在這一年，通過大大小小十數(shù)個咨詢項目，我是這樣做的：

• 第一步，我通過在不同客戶項目的實踐中打磨和定義了每個階段清晰的輸出件，產(chǎn)出了《DDD工作坊準入條件和產(chǎn)出物圖例》。這一步就相當于通過Tasking確定程序的輸入和輸出，以及定義測試驅(qū)動開發(fā)中的測試用例。
• 第二步，在確定了輸入輸出后，我繼續(xù)通過不同項目的不斷打磨，基準化了每一個階段的操作步驟，并把每一步細化到概念介紹、操作步驟、過程圖例、要點提示四個部分，產(chǎn)出了《DDD工作坊操作手冊》。這一步就相當于通過測試驅(qū)動的方式，進行了程序“處理”過程的實現(xiàn)，并且還通過小步迭代的方式，對操作過程進行了一遍又一遍的迭代。
• 第三步，在整個操作手冊完成之后，基于操作手冊，重新梳理抽象出了適配這個操作手冊的最簡單和通常的概念，并從整個宏觀上優(yōu)化和定義了新的DDD分段式設計（戰(zhàn)略設計階段、戰(zhàn)術(shù)設計階段、技術(shù)實現(xiàn)階段），解決了之前所有我所參與過的DDD培訓所看到的知識體系凌亂，不統(tǒng)一，不順暢等問題，讓概念講解部分最小化，產(chǎn)出了《DDD工作坊概念講解》課件。這一步就相當于程序設計和開發(fā)過程中，通過高度抽象，進行分層架構(gòu)并實現(xiàn)架構(gòu)演進的過程。
• 第四步，通過項目開發(fā)實踐和進一步總結(jié)，結(jié)合多種以領(lǐng)域為核心的分層架構(gòu)思想，不斷打磨形成了適配整個基準化DDD的基準化代碼樣例（https://github.com/howiehu/ddd-architecture-samples）。實現(xiàn)了代碼化落地。
• 第五步，繼續(xù)通過不斷的實踐、打磨和總結(jié)，產(chǎn)出《DDD成熟度評估標準》。

這樣，就通過實戰(zhàn)驗證的方式，從確定交付物開始，一步一步的增量式的完成了DDD設計過程的基準化，這也很像我們做軟件設計時通過TDD而達到的“簡單設計（增量式設計）”思想。

結(jié)果

DDD的思想和設計過程，是公開并且沒有什么保留意義的，所以，我在這里也選擇分享給大家，以便為DDD在中國的落地和完善貢獻一份力量。

同時，我也正在建立一系列的DDD基準化公開材料、社區(qū)和培訓，我未來會將這些內(nèi)容逐步發(fā)布到Github的“領(lǐng)域驅(qū)動”組織之中，地址如下：

• https://github.com/domain-driven

而文章中所說的基準化的領(lǐng)域驅(qū)動設計產(chǎn)出物如下，未來我會繼續(xù)進行不斷的打磨和優(yōu)化：

• 《DDD工作坊準入條件和產(chǎn)出物圖例》（提取碼: 9jza）
• 《DDD工作坊操作手冊》（提取碼: uu1d）
• 《DDD工作坊概念講解》（提取碼: b4ft）
• 《DDD基準化代碼結(jié)構(gòu)樣例》
• 《DDD成熟度評估標準》(還在完善中，請期待)

對于這些基準化的產(chǎn)出，我已經(jīng)通過帶領(lǐng)7個新咨詢師進行了可復用性的驗證，這些新咨詢師只需要通過我講解或示范一遍，就能夠獨立承擔后續(xù)的DDD設計咨詢工作，并且還能夠?qū)崿F(xiàn)概念和手法的一致性。

至于“By Experience”，則只剩操作者個人經(jīng)驗的高低，和智商的天花板了。