面向對象與領域模組化

原文：http://www.jdon.com/mda/modeling.html

面向對象與領域模組化

需求分析方法演變

　　曆史上，對需求分析方法可以說經過三個階段：

　　第一階段：圍繞資料庫的驅動的分析設計，新軟體項目總是從設計資料庫及其字段開始。這個階段特征就是圍繞資料庫程式設計，典型的是 DBase/Foxpro，以及後來的Delphi/VB技術。

　　這種圍繞資料庫分析設計的缺點非常明顯：首先，不能迅速有效全面認識反映需求，世界不隻是由簡單的關系資料組成，而且 使用關系資料來反映現實需求，不符合人類自然思維（OO才是），是一種扭曲的分析方法，特别對于初學者，他們接受資料庫分析方法的難度反而可能會大于OO分析方法，現在很多職業學校和社會教育訓練，基礎課程從資料庫開始，從某種程度上，是曆史倒退， 嚴重阻礙中國軟體發展的程序。

　　圍繞資料庫分析極其容易導緻過程化設計程式設計，圍繞資料分析和過程化程式設計是一對惡魔，資料庫結構确立後，就讓普通程式員寫SQL 語句，SQL語句執行有明顯的先後順序，在這樣順序過程程式設計思維中，OO思維就難以生存。長此以往，成為習慣後，就很難改變到 OO設計上，是以，傳統程式設計經驗越豐富，轉變到OO設計就越難。

　　在運作性能方面：圍繞資料庫分析設計容易導緻軟體運作時負載集中在資料庫端，系統性能難于擴充（走上集中式、昂貴的、高風險的大型機模式）， 閑置了中間件J2EE伺服器分布式叢集處理能力，就是使用了叢集，也分擔不了負載。

　　最後，我們必須認識到：對象和關系資料庫存在阻抗，本身是沖突競争的，他們是兩種分析看待需求的流派，可以說是水火不容， 要麼你采取資料庫分析設計以及過程化程式設計，要麼完全采取OO，現在使用.NET和Java這樣OO語言的人很多，但是70%左右都是使用OO語言

編寫傳統過程化系統，在Java中這樣做，會有極差性能；而這種現象在.NET中又極容易得到縱容，.NET是一個系列陣營，正如Windows系列一樣， 當你和别人說，你在使用Windows，别人可能覺得你沒有落後時代，但是他們哪裡知道你在使用Windows 3.1呢？

第二階段：面向對象的分析設計方法誕生後，有了專門的分析和設計階段之分，我們使用UML符号來表達分析設計思想，分析設計進入了一個相對更高的層次，擁有了自己一套科學且藝術的方法論。但是有一個緻命缺點：分析階段和設計階段是斷裂的，互相不能很好銜接，為什麼？

　　首先，我們看看分析人員和設計人員在職責重點工作是什麼？

　　分析人員的職責：是負責從需求領域中收集基本概念。而設計人員的職責：必須指明一組能北項目中适應程式設計工具構造的元件，這些元件必須能夠在目标環境中有效執行，并能夠正确解決應用程式出現的問題 兩個階段兩者目标不一緻，分析人員隻管需求分析，至于是否适合設計，或者能夠導出适宜設計的分析結果，這個尺度很難衡量和把握；

　　而設計人員因為照顧代碼可運作，是以，經常可能會抱怨分析員給出的結果過于粗糙，不适合設計，這樣分析設計兩個階段就導緻分裂，項目失敗。

　　在這個階段，雖然有UML幫助，但是UML不是思想，打個比喻：會CAD的繪圖員就是建築師嗎？很顯然，UML就是CAD圖符号，UML不等于分析設計思想。 是以，有人說UML不是銀彈，這些就象說中醫不是科學一樣繞人（中醫就不是西醫，當然就不是科學）。

第三階段：融合了分析階段和設計階段的領域驅動設計（Evans: DDD）。2004年Eric Evans 發表Domain-Driven Design –Tackling Complexity in the Heart of Software （領域驅動設計 ）簡稱Evans DDD， 領域模組化是一種藝術的技術，它是用來解決複雜軟體快速應付變化的解決之道，是以，從Evans DDD通篇文章中，你找不到科學象征的定理和公式，當然如果 你試圖尋找這樣尋找，你也就陷入了“中醫是不是科學”怪圈了。

　　Evans DDD抛棄了分裂分析模型與設計的做法，使用單一的模型來滿足這兩方面的要求。這就是領域模型。 單一的領域模型同時滿足分析原型和軟體設計 ，如果一個模型實作時不實用，重新尋找新模型。如果模型沒有忠實表達領域關鍵概念時，也必須重新尋找新的模型。 模組化和設計成為單個疊代循環。将領域模型和設計緊密聯系。是以，模組化專家必須懂設計。

領域模組化的重要性

　　如果你說一個軟體開發需要經過需求、分析和設計三個階段的話，那麼可能反映你的思想已經落伍，軟體開發現在是 經過需求、模組化階段，混合了分析和設計階段，可以更激進地說：我們國家的系統分析員和系統設計員考試也許應該合并了， 合并成模組化專家的考試，否則，這些都是中國軟體落後世界十年的證據，可悲的是：我們自己可能都不知道。

　　Evans DDD可以說是近期與SOA相提并論的兩大重要技術思想，SOA是着重于軟體內建方面；而EvansDDD才是着重我們軟體開發上， 在大部分情況下，軟體開發重要程度不亞于軟體內建，但是因為軟體開發方面開源力量沖擊，軟體內建上工業廠商利潤最高， 是以，工業廠商在SOA叫得最響，我們參加得各種會議幾乎都是SOA，當心被誤導，工業廠商從來不會告訴你事實得争相。

　　 沒有面向對象的分析設計，哪裡面向對象的構件或元件？過去經驗不是證明：我們使用大量的構件元件，卻在編制面向過程的體系？

　　以EJB2為例子，在EJB2過去大部分系統中，我們常常以資料庫為中心，實體Bean因為特殊技術原因，僵硬一塊，變成資料庫 的代名詞，我們圍繞實體Bean編制出大量的值對象Vale Obejct，或稱為DTO（Data Transfer Object），在這樣系統中，從對象 的名稱也可以看出，對象是為資料服務的，對象從屬于資料庫的。

　　現在，要徹底改變過來，OO就是以對象為主，資料庫是從屬對象設計的，如果說EJB2的實體bean技術讓你不得不走上傳統過程化程式設計歧路，那麼 EJB3已經更正了實體Bean設計缺陷，從EJB發展可以看到一個側面：工業廠商更多關心的是功能，而不是設計？

　　隻有誰才真正關心你的軟體設計和代碼品質？隻有你自己。我不是提倡都不要參加工業廠商的會議，而是需要每個人冷靜想想： 到底誰是自己代碼的主人？

　　領域模組化屬于與具體.NET或Java技術無關的設計思想，有人總是說：.NET比Java簡單，其實這又是一個大誤區，如果都達到同樣設計水準，無論使用.NET或Java，都需要付出同樣的努力；那為什麼有人覺得.NET簡單，那是因為設計要求降低了，參見這篇.NET的DDD文章。

分層架構

　　分層架構是現代OO軟體企業系統的基本架構，隻有分層才能達到良好的可拓展性和維護性。基本三層：表現層、業務層和持久層 ;J2EE中表現層和持久層有成熟架構支援，應用重點在業務層。

　　業務層根據Evans DDD，可以再細分為應用層和領域層兩種，在業務層設計編碼中，大量應用OO設計原則和設計模式。領域層定義：負責表達業務領域概念、業務狀态以及業務規則，是整個業務軟體核心和重點。 應用層定義：負責完成功能，并且協調豐富的領域對象來實作功能，不能包括業務規則，無業務狀态；

　　每個層都是内聚的，并且隻依賴它的下層，為了實作各層的最大解耦，IOC/DI容器是目前Java業務層的最好選擇 。

　　 沒有分層架構的快速開發基本是旁門左道，不如傳回Foxpro和Delphi/VB兩層時代。将本屬于業務層的邏輯交由表現層來處理的快速UI方式也是一種旁門左道。快速開發必須基于良好的品質，雖然良好的分層架構帶來開發效率的降低，但是這些也是可以有方法解決。

模組化與項目管理

　　 在我們大多數從軟體項目管理上尋找軟體永恒解決之道時，他們可能沒有意識到又在範“緣木求魚”老毛病了， 打個比喻很容易明白這個道理：冷兵器時代（也就是火槍沒有沒有發明之前），各種排兵布陣可能在作戰指揮時 很有效；但是到了火器時代，所有的過去作戰方式就落伍了；當然到了現在資訊化戰争時代，更是天壤之别。

　　 Evans DDD領域驅動模組化的誕生，對過去傳統的項目管理都提出挑戰，當我們還在争論RUP好還是靈活好的時候， 誰會想到我們應該采取圍繞統一領域模型的疊代驅動開發呢？

　　 有人可能還在疑惑？我接到一個大項目，那麼我的模組化和架構設計時間應該是5個月還是5年呢？當然應該回答他：都不行，需求是多變且複雜的，計劃趕不上變化，現在就應該開始DDD模組化。