我第一次捧起老艾那本《領域驅動設計》，驚為天人。吾輩上下求索數年，這不正是終極之大道嗎？結果只三天熱乎勁兒，“什麼玩意兒”是對這本書的最好評價。好好的一本書讓我“棄之如敝履”，差點就“小舟從此逝,江海寄餘生”了。幾年過後讀了網上一些老baby寫的吐槽DDD的文章，幾乎視其為知音啊，那概括的真是精闢，絕對是個性情爽快的真漢子。借他的花我也獻獻佛，也說說DDD這點事兒，好好的一門兒學問怎麼現在變得神乎其神上升到哲學、玄學的地步，不得不感慨“江山代有才人出”。
上面的圖展示了使用DDD的六個困境，相信每一個學習者都會遇到其中的一個兩個或多個。
第一層：“本末倒置”，技術人員喜歡將精力放在戰術部分而忽略了戰略，喜歡討論各類設計模式、框架，部分個體系統設計的相當不錯，整個系統確是千瘡百孔。這種抓不住重點的情況，造成你雖然使用了DDD，確看不到成效。再加上ODD這種設計方式做起來也挺複雜，上下怨氣沖天。最終給你的結論就是“DDD不行”。此外，過度關注技術使得你的系統的好壞完全依賴於程式設計師的個人素質，問題是好的程式設計師全乾管理去了。上有屁股下有臉，他也沒時間從細節上把握系統建設。DDD的帶頭大哥“Vaughn Vernon”在其名著“實現領域驅動”一書中開端便寫“戰略”，那就是告訴您這是需要第一時間關注的部分。您在讀書的同時也得猜測作者為什麼這樣安排章節，為什麼與老艾那本開山之作組織方式不同，這得細心品味一下才行。
第二層：“門檻高”，即便是DDD的戰術部分，對於研發人員也有較高的要求，如：資料庫設計、程式碼規範、全域性系統理解度、設計模式、系統優化策略……。過去您搞程式導向，要考慮資料庫的優化；現在您搞DDD除了資料庫那點活兒，您還得考試模型的設計，比如有哪些模型？它們間的關係是什麼？，裡外裡實現難度增加了一倍以上。再者，DDD還鼓吹頭腦風暴（其實就是開會）呢？您作為一個高階工程師或者團隊扛把子，不得參加參加？而實際情況，一天已經800個會了，誰還有時間、有精力去做模型設計。好不容易有個喝口水兒的時間，想來還有一個千字週報沒寫。
第三層：“晦澀”，網上DDD相關文章中很喜歡使用晦澀語言。大部分文章作者的分享精神值得讚揚，可就是有些大師喜歡搞玄學，本來一個事情可以用簡單的語言表達出來，我們必須得上升到哲學層次。寫文章的目的不是“傳道、授業和解惑”， 是為了欣賞你們一副無知的樣子。DDD裡就那點東西，說白了就是建設前先把大系統拆分一下，再對小系統按其情況選擇一個程式設計模型，再稍微注意一點服務間的互動，這事兒就齊了。那些專家級文章再多寫一點就開始指點人生了，這臣妾消化不了啊。
第四層：“無案例參考”。比如微服務，你可以找到大量的落地方案，對於DDD有價值的參考非常少，大部分的案例都脫離了實際的業務，離開領域談設計也不能說沒意義，現實中您計劃使用DDD的業務場景可能非常複雜，一個小細節都可能阻礙工作的進展。所以只有實際參與過DDD專案才能瞭解系統從分解到建模再到落地的一系列流程中所應注意的東西。片面的案例對於有經驗的工程師可以說明問題，對於小白則造成了不小的困擾，從內心深處排斥學習。可話說回了，也不太可能把自己公司的專案全擺出來讓您看，這涉及到法律及安全的責任。這種情況基本無解，比較好的方式是找個不重要的模組揹著領導自己搞一把，萬一成了呢？
第五層：“過度吹噓”，部分文章和書籍作者過分的誇大某些戰術架構的優勢而忽略了其缺點，甚至對於DDD本身也做了誇大，造成開發與運維成本的成倍增長及至於系統無法快速擴容甚於不得不重寫，比如CQRS、ES就特別容易被濫用。此話羞於開口，我知道ES的程式設計模型可從來都沒在實際系統中搞過，一是有代替方案二是害怕（程式碼都是寫給自己的，出了問題您也得自己維護，除非您打算寫完就直接跑路）。在座的您各位也包括我自己應該是很喜歡技術的，面對花花世界中那些亮眼的、高大上各類技術和名詞，很容易被其誘惑。到不是說多學點技術不好，而是要學會如何控制自己去選擇最為合適的技術方案，這是您對公司的責任。請對技術保持敬畏之心，那東西是雙刃劍可以成全你也可以逼你揮刀自宮。
第六層：“營銷綁架”，軟體行業喜歡把簡單的東西搞複雜，主要的目的就是讓人覺得很高大上，越晦澀越好。讓人聽上去感覺很牛掰，但是聽不懂。如中臺、低程式碼、DDD。這樣的系統具備極高的營銷價值，但落地非常困難，尤其是在資源方面無法與理論對齊的時候。銷售拉專案時通常會豎立各種Flag，可只要專案一到手就由不得客戶了。至此，DDD就淪落為一個拉專案的口號，可憐那！
面對上面的六種困難，的確是沒什麼好的解決方案，即使說出來也不過是紙上談兵。家家過日子，家家有本難唸的經。“盡人事，知天命”：前一句告訴您需要加強自身的修養，需要時時報有一種客觀、務實乃至對於技術敬畏的態度；後一句告訴您世上很多事情本身就是無解的，您上面有領導，領導上面還有領導。那就學會聰明一點換個思路解決問題。我們都是搞技術的，技術是樸素的，千萬別天天誇誇其談。您個人是爽了，但活總得有人幹，讓下屬天天后面罵著您也不好不是嗎 ？
另外，假如您在組織內有一定的權力，DDD可以幫你打通任督二脈，至少在戰略上還是可以有效的指導系統建設的。假如您空有一身抱負卻攤上了一個不懂還要裝懂的領導，那就熬他，看看誰最終笑在最後。最後一點，請把戰術設計部分的責任放在您的團隊最靠譜的那個人（技術好還聽話）身上或乾脆自己來，尤其是涉及需要使用ODD的業務時，千萬別天真的組織一堆人坐在一起聊設計。人一多就眾口難調，七嘴八舌的一會兒就把您帶歪了，還頭腦風暴？整個就一噴空沙龍。家有千口主是一人，如果你敢拉會那就需要保證這裡有一個人敢拍板兒做決定。最後，請務必不要忽略人性中的自私，同水平技術人員討論的時候最終往往就對人不對事兒了，容易讓團隊產生矛盾，萬事以合為貴嘛。
如果您下面有幾個比較有能力的大哥，放到不同的業務中。服務拆分（拆分階段儘量讓骨幹參加，後續這幫大哥還得負責各子系統建設呢，不過得有個主事兒人能拍板兒）的好，實施階段好一點差一點也太不影響什麼（嚴肅來講：是因為好的拆分能夠明確子系統間的邊界，這種天然的隔離機制會消除部分不良設計所帶來的影響），使用者又不知道，反正只要功能對就行。好的系統也不是設計出來，是迭代出來的。再說了，有生之年我估計也沒機會參與火箭、太空梭的軟體設計了（這類系統不允許BUG的存在，需要採用非常嚴謹的軟體開發流程進行管控），讓我們擁抱迭代吧！！！
本節談了DDD的困境，也說了一點團隊管理的事兒。公司不同，文化不同，按需採用合適的、適應您團隊的管理辦法和系統實施技術方案。另外，心急的爺們不要著急想看程式碼，先修煉內功，高手都需要內外兼修的。下次我們們聊聊DDD都說了點什麼東西，怎麼也得有個大概的感性認識吧。您就算再不願意看到那些晦澀難懂的詞我也得說（主要是不說我也不知道用什麼詞代替，我也在是在DDD的路上掙扎呢，回頭沒岸了），萬一和同行聊的時候您滿嘴大白話，不專業。