DDD該如何學？
2006年，國內網際網路才剛剛萌芽，大家甚至還不習慣網購，大多數在校生都在宿舍裡刷魔獸世界副本。但企業軟體開發卻得到了蓬勃發展，各大公司和事業單位都紛紛進行資訊化轉型。
然而大家很快發現，企業應用業務邏輯的複雜度要遠遠高於技術本身，且企業IT人員很難描述清楚他們真正的業務，廣大程式員也普遍缺乏挖掘真正需求的能力。整個開發過程更多的是瀑布式，開發人員一次性收集需求，可能半年後才會和業務人員再次溝通。大多數企業軟體就是在這樣的環境下硬著頭皮上線的，其質量可想而知。
隨著《領域驅動設計》中文版的首次釋出，DDD（Domain-Driven Design，領域驅動設計）的概念正式進入中國。當時業界普大喜奔，認為它能指導程式設計師更精準地收集領域知識，進行更合理的設計，企業應用的銀彈出現了。
當時的我正處於多層架構的啟蒙階段，掙扎於企業系統的泥潭，又剛剛被Martin Fowler的《企業應用架構》洗了一遍腦，自然也隨波逐流地買了一本，捧在手裡翻來翻去，但反反覆覆就是看不懂。當時以為在貧血模型裡面加幾個方法就是領域模型了，把DAL或DAO改名成Repository就是資源庫了。而且身為程式設計師，自然願意去關注那些能指導我們寫程式碼的戰術設計方法，對那些真正能幫助我們進行合理設計的戰略設計方法，則視而不見（可能是因為看也看不懂）。
多年過去，這本書仍然作為我的鎮宅之寶戳在書架顯眼的位置，希望能有識貨的朋友來訪時能一眼瞧見，伸出大拇指羨慕嫉妒地說“這麼老的書你都有”。或者偶爾拿出來拍張照片在朋友圈晒晒，以炫耀自己當初的見識。順便翻開一頁，把鼻子湊上去聞一聞來自12年前的墨香。
7年之後Vaughn Vernon出版了Implement Domain-Driven Design，簡稱IDDD。一年之後由同事翻譯的中文版《實現領域驅動設計》也相應出版，當時被看做是能讓DDD落地的書（畢竟書名裡有個“實現”嘛）。然而我在專案技術負責人的帶領下，在眾多有經驗的架構師的指導下，仍然沒有弄明白。之前看過的相關知識均已遺忘殆盡。限界上下文、上下文對映這些名詞只是似曾相識。
兩年之後《領域驅動設計模式、原理與實踐》問世，簡稱PPPDDD。社群對這本書的評價非常之高，甚至認為在IDDD之上。只可惜這本書的翻譯質量並不高,我翻了幾頁之後又束之高閣了。
今年年初，專案上的架構小組又開始組織學習DDD。所使用的“教材”是英文版的PPPDDD。在同事的激勵下，我開始重整旗鼓，啃這本英文版大部頭。開始精讀之後，才發現這是一本很水的好書。說它水是因為它的編排並不足夠細心，甚至有不同章節的兩段文字完全相同的現象，還會花30頁的篇幅去介紹一個基於NHibernate的資源庫實現。說它好是因為面面俱到，把所有戰略模式和戰術模式都介紹了個遍，還有大量程式碼去幫你實現各種戰術模式，可以說相當落地。
在學習的過程中，我常常翻閱IDDD中的相關章節進行補充閱讀，發現當初晦澀難懂的概念慢慢變得容易起來。應用服務和領域服務不再傻傻分不清楚，不同的上下文對映方式也能在工作中找到對應的例子。對於DDD，感覺快要開始入門了。
與此同時，IDDD的精華版DDDD（Domain-Driven Design Distilled）也出版了。作者總結了過去幾年在DDD方面的實戰經驗，將IDDD中的諸多內容精簡昇華。在很多概念處都標註了IDDD中的相關章節，可以算是IDDD的一個索引。
其中文版《領域驅動設計精粹》由ThoughtWorks同事覃宇和笪磊合作翻譯。這是我讀過的最良心的一本書籍，因為它包含了大量譯者註解，解釋了很多書中沒有解釋清楚的概念（畢竟是精粹本）。還有些有爭議的觀點，譯者也毫不客氣地給出自己的看法。
像這樣註解超過原文的情況在其他書中是很少見的。每一處註解都傾注了譯者的心血和精力，這背後勢必包括大量資料的查閱和研究，而且很多解釋都夾帶了濃濃的ThoughtWorks特色，使得這樣一本薄薄的書變得豐滿充實起來。
如果你讀書快的話，可能兩個小時就讀完這樣一本書。但如果把原書和註解中的推薦文章和書籍讀完，恐怕要一個月。我順著書中的指引，找到了ThoughtWorks洞見上的所有DDD文章，讀完之後，世界觀崩塌了，感覺自己剛要入門就要放棄了。具體原因請參考連結中的文章。
其實，不管是DDD、IDDD、PPPDDD還是DDDD，講的都是理論，充其量會附加一些作者杜撰的示例。相信我，光學習理論是沒有用的，你必須將其應用於實踐，在自己的真實專案裡演練DDD。這時你才會發現，那些白紙黑字的概念，在讀書時似乎搞清楚了，但一使用起來，反而更迷惑了。就像最基本的子域和限界上下文的關係問題，ThoughtWorks的首席諮詢師肖然就和Vaughn Vernon的理解就相去甚遠。到底該“信誰”？那就似乎更要通過實踐來出真知了。