ddd quickly 中文版譯者序

在去北京參加infoq大會之前,我就開始了對DDDQuickly的翻譯工作,如今,在我和泰穩的努力下,它終於可以跟大家見面了。我心甚慰。
可以去infoq中文站免費獲得此迷你書
 
======================================
 

序言

在2004年之前的某一天,我跟所在部門的一個設計師進行溝通,當時他爲自己的一個思路興奮不已,而我要做的事情就是跟他討論清楚他頭腦中的那個想法,然後寫出需求和設計文件來。大家可能會注意到,很多時候,需求是從設計中反推出來的,這被一些專家稱爲“需求的反向工程”。其實我更多地認爲這是由於我們現在糟糕的工作現狀決定的,有諸多的因素導致需求或者設計被侷限在僅有的幾個人的知識體系中,但如果有心去細察,會發現他們各自的理解又各不相同。

回到剛纔說到的那次溝通上,當那個設計師把自己的得意之作描述完畢後,我在紙上用UML圖畫出了他的主題思路,然後我們針對細節開始探討並在圖上改改畫畫。最後的修訂結果顯示,他的很多"創舉"是多餘的,經過精簡後的UML基本上顛覆了他原有的思路。現在我還記得那位同事的一聲嘆息:"一週的功夫白費了……"

其實在整件事情中,他有他的得失,我也有我的收穫和困惑:我意識到對統一的核心模型進行探討和簡化的重要性,但應該如何把這樣的過程程式化,讓它在更多的同事的工作中發揮作用呢?


這樣的問題糾纏了我好久,終於有一天,我得到了一本如字典般的硬皮《Domain-Driven  Design》(我們親切地稱它爲"DDD")原版書,從中找到了答案。然後,我參與了DDD中文版的審校工作和DDD註釋版的註釋工作。再後來,InfoQ中文站的總編霍泰穩又邀請我一起做了《Domain Driven Design quickly》這本書的翻譯工作。

曾經有人要我用簡練的詞彙描述DDD的中心思想,我個人認爲這是一個比較難的工作,但我願意去嘗試。我的回答是"關注精簡的業務模型及實現的匹配":

1. 如果你瞭解"模型"的定義是對現實的有選擇性的精簡,然後用這樣的觀點去讀DDD這本書,你就會發現,DDD其實沒有什麼太多的新鮮玩意,它更多地是可以看作是面向對象思潮的迴歸和昇華。在一個"萬事萬物皆對象"的世界裏,哪些對象是對我們的系統有用的?哪些是對我們擬建系統沒有用處的?我們應該如何保證我們選取的模型對象恰好夠用?

2. 前面的選擇性問題只是解決了一個初步框選的問題,對象並不是獨立存在的,它們之間有着千絲萬縷的聯繫。這種扯不斷理還亂的聯繫構成了系統的複雜性。一個具體的體現就是,我們修改了一處變更,結果引發了一系列的連鎖反應。雖然對象的封裝機制可以幫我們解決一部分問題,但那只是有限的一部分。我們應該如何在一個更高點的層次上,通過保留對象之間有用的關係去除無用的關係,並且限定變更影響的範圍以來降低系統的複雜度呢?

3. 在DDD以及傳統OO的觀點中,業務而不是技術是一個開發團隊首先要關注的內容,衆多的框架和平臺產品也在宣稱把開發人員解放出來,讓他們有更多的精力去關注業務。但是,當我們真正去看待時,會發現,開發人員大多還是沉溺於技術中,對業務的理解和深入付出的太少太少。其實要解決這個問題,就要先看清楚我們提煉出來的模型,在整個架構和整個開發過程中所處的位置和地位。我們經常聽到兩個詞,一個是MDD(模型驅動設計),一個是MDA(模型驅動架構)。如果DDD特別關注的是"M"(以及其實現),那麼,這個M應該如何與架構和開發過程相融合呢?我經常會看到我們辛苦提取出來的領域模型被肢解後,分散到系統的若干角落。這真是一件可怕的事情,因爲一旦形成了"人腦拼圖",就很難再有一個人將它們一一復原,除非這個人是個天才。

4. 很多面向對象的教材,都會告訴你若干的技巧,讓你去機械化地處理模型和對象實現,但是這些教材通常會忽略一個大的上下文環境,就是應該由哪些具有什麼樣素質和技能的人來處理模型和對象實現,或者說白了,就是應該用什麼樣的團隊模型來匹配業務模型。不同的模型,需要不同的團隊模型的支撐,不同的團隊模型也會讓一個模型實現更優秀或者更糟糕。

5. 相信很多人讀過ATM機的例子,你發現自己徹底明白了用例應該怎麼編寫、模型怎麼提取和實現,但是當你信心十足地去開始你自己的項目時,你又會發現你的思路片段化了,所有你明白了的技能在你的新項目中好像用不上。算了,還是老的工作思路和工作方式比較順手,於是一切都照舊會到了老的套路上。那麼,面向對象技術或者說我們提煉出來的模型應該如何在大型項目/團隊中使用呢?我們是應該要求一個項目使用統一的模型,還是應該把它們分成不同的模型?我們應該如何抉擇?

……

在實際的應用過程中,我相信每一個有心人都會提出比我在這裏列舉出來的還要多的問題,沒有關係,DDD這本書都能給你所需的答案。

當然,"DDD"作爲傳統OO範型的探索和昇華版,也存在着一些不足和未涉及的領域,例如:在安全、權限方面的考慮,其基本構造塊的適用範圍和決策標準,與開發框架之間更好的融合性等問題。還好,我們都知道"盡信書不如無書"的道理,在閱讀任何著作時,都應該帶着自己的疑惑和批判精神去閱讀,你的任何關於DDD的深層思考和討論,都可以在它的配套網站或者InfoQ中文站網站中發表。

如果你認爲閱讀DDD這麼一本如字典版的大厚書時間上不太允許,那麼請允許我爲你介紹一本簡化版的小書《Domain Driven Design Quickly》,經過我們的努力,InfoQ中文站已經將其翻譯成中文版——《領域驅動設計精簡版》,並作爲國慶禮物奉獻給大家!

那還等什麼呢,祝您開卷有益,閱讀愉快!

孫向暉

2007年9月26日於泰安

 

 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章