DDD實施經驗分享—價值導向、從上往下進行（圈內第一個吃螃蟹DDD實施方案）

閱讀目錄：

• 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等重要的技術概念。在此先打個小廣告推廣下。）

 

做者：王清培

出處：http://www.cnblogs.com/wangiqngpei557/

本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面