閱讀目錄：

• 1.背景
• 2.從業務開始
• 3.從戰略到戰術
• 4.藉助外力推動研發（QA、領導、自動化測試）
• 5.領域模型與SAAS平臺的核心（價值最大化）
• 6.最後

1.背景

DDD本身的技術就不介紹了，本篇文章要分享下我在推廣DDD或者說實施DDD的過程中的心得和寶貴的經驗。事實證明，這是可行的方案。用好DDD是一回事，推廣DDD是另外一回事。也許已經有一套客觀理性的推廣技術的方案，但是我只能說DDD非常特殊。

我們都知道自己用好DDD問題不大，讓一兩個人用好DDD也問題不大。你也許程式碼控制能力很強，也或者你的組員對DDD都有興趣，在你的領導下，你讓他們編寫DDD模式的程式碼，問題也不大。但是作為一名架構師我們的職責是要推廣或引進適合本公司業務模式的某種技術或者最佳實踐。你或許推廣效能優化、介面設計等等，這都沒問題。但是讓你推廣一些有著很強主觀意識在裡面的東西其實很難。因為每個人的思維模式不同，對問題的理解和抽象的方式也不同。那你如何讓大家就DDD能達成一致的抽象理解呢。

你可能覺得我在吹牛B，你們公司能實施DDD。實話告訴你，我們實施了DDD了，而且效果很明顯，非常成功，有圖有真相。我用一種方式讓我們的最高領導人都一致贊成這個價值。如果你推廣DDD的角度是從技術出發，那麼我可以很肯定的告訴你行不通，在任何一家公司實施都不可能成功，除非老闆是你爸。要想成功，你得讓不懂技術的領導者能感覺到它的價值，解決了某個痛點，這樣你就成功了一半。

在強調下，作為架構師，在我們的腦子裡每天裝的不是具體的一個技術，而是全域性。你要把控的是一個面，是需要全面考慮。你可以自己回去研究某個技術，就比如我自己最近在學習JAVA、GO。技術人員每天都要學習的，懂得越多發現要學的東西越多，這是合理正常的。但是你要知道作為架構師的職責是什麼，要搞清楚你本職工作的的目標是什麼，這是我現在的良師益友給我最多的提醒和指導（藉此真心的感謝我的領導）。

所以，我文章的標題裡有價值導向，這符合企業運營規則，也符合我們人的思考方式。技術導向，是技術人員的思考習慣。這沒錯，但是如果我們要影響別人就要跳出來思考問題。

第一版是我親手設計的，感覺還不錯。

2.從業務開始

實施DDD得有個前提，它是解決業務問題的，不是解決某個技術問題的。或者準確點講，它是解決業務系統問題，不是解決非功能性技術問題的。這點要認識清楚。然後你要考慮你從哪個層面切入到整個研發流程中，讓DDD的東西在某個環節發揮一定的作用，短期不要太急，不要一口氣全部推廣出去。這會讓人覺得你是一個技術偏執人員，不是一個理性的架構師。切忌。

如何從業務開始就為其創造價值。這裡有一個痛點就是業務術語、業務模型不統一，溝通成本太大。如果你能減少產品和技術的溝通成本，其實你就創造了價值，而且價值是巨大的。你可以引入DDD的知識來解決。有一個小竅門就是你剛開始不要提及什麼DDD等一些專業的技術詞彙，你要引導往這個方面去走。你可以說我們需要一個手冊，裡面包含了專業的業務術語解釋，如果可以的話在包含點基本的業務結構。引導和合作的方式讓產品整理出來，你在加以修改和整理，因為你是知道DDD的整個路徑的。

這個時候其實你已經在實施DDD了，千萬不要覺得DDD就是那些程式碼。

當業務手冊逐漸成形，就會順其自然的引導到技術人員那裡。然後你在找個痛點將戰術設計引入研發team中。還是那句話，不要太強調DDD的戰術。從頭到外如果你都不提DDD的概念讓DDD落地才是最理想的。

慢慢的從OO的角度引入高內聚低耦合，然後通過DDD的戰術幫助研發去理解。

3.從戰略到戰術

解決了業務問題，帶來了價值。這是一個好的切入點，我們繼續前行。慢慢開始引入DDD的戰略概念，前提是你要得到大家的信任，要負責任。

引入戰略設計模式，開始用專業的DDD戰略術語進行交流和引導。當然如果你們的交流和討論是敏捷的最好，藉助白板快速達成一致。經過一段時間再通過現在正式的會議進行一個概念鞏固。此階段需要藉助大量的分享和培訓讓這個氛圍起來。先達成共識。

到目前為止我們已經全面開始DDD的推廣，好幾個研發部都看見了它的價值。好東西不要你多說，群眾的眼睛是雪亮的。我們還實施了單元測試，這是何等的驕傲。核心的業務物件我們慢慢開始引入單元測試，手把手的教研發怎麼寫。

4. 藉助外力推動研發（QA、領導、自動化測試）

有時候需要藉助一些外力來幫助我們實施推廣一些東西，這應該是通用的方式方法。那麼DDD需要藉助哪些力量來讓推廣更加的容易點。

可以藉助QA來強調質量，比如引入codereview、同時把你的DDD包含在裡面引入。要記住你的目標。

還可以藉助你的領導來推廣，當然有領導幫忙推廣是幸福的，但是你要做好售前售後工作。彆強推，適得其反。

還可以藉助自動化測試的實施來推廣你的領域模型提煉。通過單元測試讓研發慢慢的重視領域模型的高內聚低耦合。

5.領域模型與SAAS平臺的核心（價值最大化）

其實，到最後企業的SAAS平臺建立首先需要的就是業務模型。你可以藉助這個價值讓DDD的價值最大化。而且事實也是確實如此。研究SAAS的人都瞭解，核心業務模型基本上是很少變化的。外圍的個性化都是基於核心模型在擴充套件。

6.最後

其實僅憑一篇博文很難說清楚細節。我只是給熱愛DDD的同志們分享點我自己的可行方案和心得。其實這裡面還有很多寶貴的東西值得分享。

最後還想說一句，作為一名架構師要知道“價值導向”、“風險驅動”。要為企業創造價值，要為企業規避風險。你只要做好這兩點就已經是相當的厲害了。要有耐性，要負責任，要做到良師益友，很多時候技術是要引導的，架構是在不斷的演化中，所以不要急。目的是要做成，而不是我試過沒成功。

本章內容我會在我的下本書中詳細的總結出來（《B2B電商平臺系統架構設計》，一本講解B2B業務模式的系統架構設計，裡面將包含DDD、SOA、SAAS、GRASP等重要的技術概念。在此先打個小廣告推廣下。）