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