面向?qū)ο笈c領(lǐng)域建模

板橋里人 http://www. 2006/12/6（轉(zhuǎn)載請保留）

多變且復(fù)雜的需求

　　如果沒有多變的需求，也許就沒有今天的面向?qū)ο筌浖?，我們曾?jīng)試圖通過需求管理、需求跟蹤等等管理方式約束和減少需求頻繁更新帶給軟件的沖擊，可是這樣下去的結(jié)果只有一個：使得軟件更加僵化；或者程序員更加 勞累。

　　需求不但多變，而且經(jīng)常是不可能第一次就能掌握，需求反映了某個領(lǐng)域的專業(yè)知識，例如數(shù)學(xué)、管理、財務(wù)或 電子商務(wù)等等，每個特定案例需求又有其特別復(fù)雜之處，幾乎沒有人能夠第一次接觸就可以深入掌握這些專業(yè)領(lǐng)域的 需求本質(zhì)，就是專門的建模專家也不例外。

　　既然需求是多變而且復(fù)雜的，所以，就不能使用“堵”式方法對其進行控制和管理，只能順勢而為，通過靈活多變的 以及迭代反復(fù)的方式逐步抓住需求，并且作為需求的實現(xiàn)軟件系統(tǒng)必須能夠迅速應(yīng)對需求變化，需求變化有多快，軟件 變化就有多快。

　　因此，對于多變的需求，我們的解決之道是：引入靈活多變的架構(gòu)，面向?qū)ο驩O架構(gòu)正是應(yīng)對多變需求而生，強調(diào)軟件的可維護性 和拓展性，OO可能不是最好方式，但是目前是最合適的；對于復(fù)雜的需求，我們的解決之道是：委派專門的建模專家跟蹤理解需求， 在需求和需求實現(xiàn)之間搭建橋梁，項目方法上采取多次迭代的敏捷軟件開發(fā)方式，逐步了解學(xué)習(xí)掌握需求。

　　在這里稍微說明一下，很多人總是將軟件和數(shù)學(xué)、管理、財務(wù)混為一談，其實軟件本身就是一門獨立的專業(yè)，是為 數(shù)學(xué)、管理。財務(wù)等專業(yè)領(lǐng)域服務(wù)的，不能期望軟件人員也是其他領(lǐng)域?qū)I(yè)人員，可是在中國現(xiàn)實中，很多人總是 無法分辨，例如某局長將整個機關(guān)考核信息化的任務(wù)交給電腦中心，這就是將考核管理專業(yè)和軟件專業(yè)混同的例子， 在考核管理和軟件之間需要一個領(lǐng)域建模專家，由他來理解或者設(shè)計考核管理體系，然后通過模型，表達成 軟件人員能夠看懂的符號，軟件人員通過模型了解領(lǐng)域。

　　曾經(jīng)有需求專家呼吁：最好將需求給所有軟件人員都了解，需求專家和一般軟件人員一起工作，這些想法的本質(zhì)是 好的，但是不可能實現(xiàn)的，不可能每個軟件人員不但了解軟件架構(gòu)和OO思想；還能夠掌握另外一個專業(yè)領(lǐng)域的艱深知識， 所以，現(xiàn)在我們提出：將領(lǐng)域?qū)＜医⒌慕y(tǒng)一領(lǐng)域模型讓所有軟件人員都了解，讓一般軟件人員圍繞領(lǐng)域模型工作，這樣 的方式才切實可行。

需求分析方法演變

　　歷史上，對需求分析方法可以說經(jīng)過三個階段：

　　第一階段：圍繞數(shù)據(jù)庫的驅(qū)動的分析設(shè)計，新軟件項目總是從設(shè)計數(shù)據(jù)庫及其字段開始。這個階段特征就是圍繞數(shù)據(jù)庫編程，典型的是 DBase/Foxpro，以及后來的Delphi/VB技術(shù)。

　　這種圍繞數(shù)據(jù)庫分析設(shè)計的缺點非常明顯：首先，不能迅速有效全面認識反映需求，世界不只是由簡單的關(guān)系數(shù)據(jù)組成，而且 使用關(guān)系數(shù)據(jù)來反映現(xiàn)實需求，不符合人類自然思維（OO才是），是一種扭曲的分析方法，特別對于初學(xué)者，他們接受數(shù)據(jù)庫分析方法的難度反而可能會大于OO分析方法，現(xiàn)在很多職業(yè)學(xué)校和社會培訓(xùn)，基礎(chǔ)課程從數(shù)據(jù)庫開始，從某種程度上，是歷史倒退， 嚴重阻礙中國軟件發(fā)展的進程。

　　圍繞數(shù)據(jù)庫分析極其容易導(dǎo)致過程化設(shè)計編程，圍繞數(shù)據(jù)分析和過程化編程是一對惡魔，數(shù)據(jù)庫結(jié)構(gòu)確立后，就讓普通程序員寫SQL 語句，SQL語句執(zhí)行有明顯的先后順序，在這樣順序過程編程思維中，OO思維就難以生存。長此以往，成為習(xí)慣后，就很難改變到 OO設(shè)計上，所以，傳統(tǒng)編程經(jīng)驗越豐富，轉(zhuǎn)變到OO設(shè)計就越難。

　　在運行性能方面：圍繞數(shù)據(jù)庫分析設(shè)計容易導(dǎo)致軟件運行時負載集中在數(shù)據(jù)庫端，系統(tǒng)性能難于擴展（走上集中式、昂貴的、高風(fēng)險的大型機模式）， 閑置了中間件J2EE服務(wù)器分布式集群處理能力，就是使用了集群，也分擔不了負載。

　　最后，我們必須認識到：對象和關(guān)系數(shù)據(jù)庫存在阻抗，本身是矛盾競爭的，他們是兩種分析看待需求的流派，可以說是水火不容， 要么你采取數(shù)據(jù)庫分析設(shè)計以及過程化編程，要么完全采取OO，現(xiàn)在使用.NET和Java這樣OO語言的人很多，但是70%左右都是使用OO語言
編寫傳統(tǒng)過程化系統(tǒng)，在Java中這樣做，會有極差性能；而這種現(xiàn)象在.NET中又極容易得到縱容，.NET是一個系列陣營，正如Windows系列一樣， 當你和別人說，你在使用Windows，別人可能覺得你沒有落后時代，但是他們哪里知道你在使用Windows 3.1呢？

　　第二階段：面向?qū)ο蟮姆治鲈O(shè)計方法誕生后，有了專門的分析和設(shè)計階段之分，我們使用UML符號來表達分析設(shè)計思想，分析設(shè)計進入了一個相對更高的層次，擁有了自己一套科學(xué)且藝術(shù)的方法論。但是有一個致命缺點：分析階段和設(shè)計階段是斷裂的，互相不能很好銜接，為什么？

　　首先，我們看看分析人員和設(shè)計人員在職責重點工作是什么？
　　分析人員的職責：是負責從需求領(lǐng)域中收集基本概念。而設(shè)計人員的職責：必須指明一組能北項目中適應(yīng)編程工具構(gòu)造的組件，這些組件必須能夠在目標環(huán)境中有效執(zhí)行，并能夠正確解決應(yīng)用程序出現(xiàn)的問題 兩個階段兩者目標不一致，分析人員只管需求分析，至于是否適合設(shè)計，或者能夠?qū)С鲞m宜設(shè)計的分析結(jié)果，這個尺度很難衡量和把握；

　　而設(shè)計人員因為照顧代碼可運行，因此，經(jīng)常可能會抱怨分析員給出的結(jié)果過于粗糙，不適合設(shè)計，這樣分析設(shè)計兩個階段就導(dǎo)致分裂，項目失敗。

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

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

　　Evans DDD拋棄了分裂分析模型與設(shè)計的做法，使用單一的模型來滿足這兩方面的要求。這就是領(lǐng)域模型。 單一的領(lǐng)域模型同時滿足分析原型和軟件設(shè)計 ，如果一個模型實現(xiàn)時不實用，重新尋找新模型。如果模型沒有忠實表達領(lǐng)域關(guān)鍵概念時，也必須重新尋找新的模型。 建模和設(shè)計成為單個迭代循環(huán)。將領(lǐng)域模型和設(shè)計緊密聯(lián)系。因此，建模專家必須懂設(shè)計。

領(lǐng)域建模的重要性

　　如果你說一個軟件開發(fā)需要經(jīng)過需求、分析和設(shè)計三個階段的話，那么可能反映你的思想已經(jīng)落伍，軟件開發(fā)現(xiàn)在是 經(jīng)過需求、建模階段，混合了分析和設(shè)計階段，可以更激進地說：我們國家的系統(tǒng)分析員和系統(tǒng)設(shè)計員考試也許應(yīng)該合并了， 合并成建模專家的考試，否則，這些都是中國軟件落后世界十年的證據(jù)，可悲的是：我們自己可能都不知道。

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

　　 沒有面向?qū)ο蟮姆治鲈O(shè)計，哪里面向?qū)ο蟮臉?gòu)件或組件？過去經(jīng)驗不是證明：我們使用大量的構(gòu)件組件，卻在編制面向過程的體系？

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

　　現(xiàn)在，要徹底改變過來，OO就是以對象為主，數(shù)據(jù)庫是從屬對象設(shè)計的，如果說EJB2的實體bean技術(shù)讓你不得不走上傳統(tǒng)過程化編程歧路，那么 EJB3已經(jīng)更正了實體Bean設(shè)計缺陷，從EJB發(fā)展可以看到一個側(cè)面：工業(yè)廠商更多關(guān)心的是功能，而不是設(shè)計？

　　只有誰才真正關(guān)心你的軟件設(shè)計和代碼質(zhì)量？只有你自己。我不是提倡都不要參加工業(yè)廠商的會議，而是需要每個人冷靜想想： 到底誰是自己代碼的主人？

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

分層架構(gòu)

　　分層架構(gòu)是現(xiàn)代OO軟件企業(yè)系統(tǒng)的基本架構(gòu)，只有分層才能達到良好的可拓展性和維護性。基本三層：表現(xiàn)層、業(yè)務(wù)層和持久層 ;J2EE中表現(xiàn)層和持久層有成熟框架支持，應(yīng)用重點在業(yè)務(wù)層。

　　業(yè)務(wù)層根據(jù)Evans DDD，可以再細分為應(yīng)用層和領(lǐng)域?qū)觾煞N，在業(yè)務(wù)層設(shè)計編碼中，大量應(yīng)用OO設(shè)計原則和設(shè)計模式。領(lǐng)域?qū)佣x：負責表達業(yè)務(wù)領(lǐng)域概念、業(yè)務(wù)狀態(tài)以及業(yè)務(wù)規(guī)則，是整個業(yè)務(wù)軟件核心和重點。 應(yīng)用層定義：負責完成功能，并且協(xié)調(diào)豐富的領(lǐng)域?qū)ο髞韺崿F(xiàn)功能，不能包括業(yè)務(wù)規(guī)則，無業(yè)務(wù)狀態(tài)；

　　每個層都是內(nèi)聚的，并且只依賴它的下層，為了實現(xiàn)各層的最大解耦，IOC/DI容器是當前Java業(yè)務(wù)層的最好選擇 。

　　 沒有分層架構(gòu)的快速開發(fā)基本是旁門左道，不如返回Foxpro和Delphi/VB兩層時代。將本屬于業(yè)務(wù)層的邏輯交由表現(xiàn)層來處理的快速UI方式也是一種旁門左道?？焖匍_發(fā)必須基于良好的質(zhì)量，雖然良好的分層架構(gòu)帶來開發(fā)效率的降低，但是這些也是可以有方法解決。

建模與項目管理

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

　　 Evans DDD領(lǐng)域驅(qū)動建模的誕生，對過去傳統(tǒng)的項目管理都提出挑戰(zhàn)，當我們還在爭論RUP好還是敏捷好的時候， 誰會想到我們應(yīng)該采取圍繞統(tǒng)一領(lǐng)域模型的迭代驅(qū)動開發(fā)呢？

　　 有人可能還在疑惑？我接到一個大項目，那么我的建模和架構(gòu)設(shè)計時間應(yīng)該是5個月還是5年呢？當然應(yīng)該回答他：都不行，需求是多變且復(fù)雜的，計劃趕不上變化，現(xiàn)在就應(yīng)該開始DDD建模。

(以上文字源自板橋本人的第四屆中國軟件技術(shù)大會“領(lǐng)域設(shè)計建模”演講稿 )