Categories
程式開發

領域驅動實戰思考(一):用TDD思想對DDD的協作設計過程進行基準化


前言

在這一年聚焦DDD設計,尤其是DDD的協作設計工作坊的諮詢工作中,我發現客戶同很多諮詢顧問之間總是存在以下衝突:

  • 體驗的“一致性”衝突
    • 客戶:希望不同的顧問在售賣方法論的時候解釋能一致;
    • 顧問:認為每個人對方法論的認識和理解本身就不同,很難做到一致。
  • 服務的“標準化”衝突
    • 客戶:希望顧問能夠將所售賣的方法論進行標準化;
    • 顧問:認為顧問所售賣的方法論本身非常靈活,需要 By Experience 依據不同的情況進行適配,標準化是做不到,並且也是不應該做的。

結合我曾經在ThoughtWorks近4年的人員培養和教學經驗,和這幾年來的諮詢經驗,我能夠理解客戶這樣要求,是因為希望能夠實現方法論的規模化落地。而在方法論規模化落地的過程中,一個很重要的問題,就是絕大多數能力一般的人,都更習慣於依據“明確的指令”進行工作,而不是依賴自己“有限的經驗”和“莫能兩可的方法論”

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

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

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

  • 對方法論的深入研究不夠:在售賣方法論的時候,現學現賣。
  • 缺乏反复的思考和打磨:缺乏機會進行反複驗證和優化,或者註意力不夠聚焦。

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

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

更重要的是,以上這個過程,是可以用“測試驅動開發(Test Driven Development)”的思想來做的!

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

那麼,我是怎樣用TDD的思想,對DDD的設計過程進行基準化的呢?在這一年,通過大大小小十數個諮詢項目,我是這樣做的:

  • 第一步,我通過在不同客戶項目的實踐中打磨和定義了每個階段清晰的輸出件,產出了《DDD工作坊准入條件和產出物圖例》。這一步就相當於通過Tasking確定程序的輸入和輸出,以及定義測試驅動開發中的測試用例。
  • 第二步,在確定了輸入輸出後,我繼續通過不同項目的不斷打磨,基準化了每一個階段的操作步驟,並把每一步細化到概念介紹、操作步驟、過程圖例、要點提示四個部分,產出了《DDD工作坊操作手冊》。這一步就相當於通過測試驅動的方式,進行了程序“處理”過程的實現,並且還通過小步迭代的方式,對操作過程進行了一遍又一遍的迭代。
  • 第三步,在整個操作手冊完成之後,基於操作手冊,重新梳理抽像出了適配這個操作手冊的最簡單和通常的概念,並從整個宏觀上優化和定義了新的DDD分段式設計(戰略設計階段、戰術設計階段、技術實現階段),解決了之前所有我所參與過的DDD培訓所看到的知識體系凌亂,不統一,不順暢等問題,讓概念講解部分最小化,產出了《DDD工作坊概念講解》課件。這一步就相當於程序設計和開發過程中,通過高度抽象,進行分層架構並實現架構演進的過程。
  • 第四步,通過項目開發實踐和進一步總結,結合多種以領域為核心的分層架構思想,不斷打磨形成了適配整個基準化DDD的基準化代碼樣例。實現了代碼化落地。
  • 第五步,繼續通過不斷的實踐、打磨和總結,產出《DDD成熟度評估標準》。

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

作者簡介

胡皓,ThoughtWorks首席諮詢師。十年以上軟件開發工作經驗。從士兵成長起來的軟件技術顧問,從事過廣泛的業務分析,項目管理,全棧軟件開發、培訓和技術諮詢等工作。當前,作為ThoughtWorks中國區諮詢BU數字化架構能力團隊的負責人,正深耕於以演進式架構、領域驅動設計、雲原生微服務為代表的數字化架構能力,幫助客戶實現軟件工程能力提升和數字化轉型的目標。