板橋里人 http://www.jdon.com 2006/12/6（轉(zhuǎn)載請(qǐng)保留）
多變且復(fù)雜的需求
如果沒(méi)有多變的需求，也許就沒(méi)有今天的面向?qū)ο筌浖?，我們?cè)?jīng)試圖通過(guò)需求管理、需求跟蹤等等管理方式約束和減少需求頻繁更新帶給軟件的沖擊，可是這樣下去的結(jié)果只有一個(gè)：使得軟件更加僵化；或者程序員更加 勞累。
需求不但多變，而且經(jīng)常是不可能第一次就能掌握，需求反映了某個(gè)領(lǐng)域的專業(yè)知識(shí)，例如數(shù)學(xué)、管理、財(cái)務(wù)或 電子商務(wù)等等，每個(gè)特定案例需求又有其特別復(fù)雜之處，幾乎沒(méi)有人能夠第一次接觸就可以深入掌握這些專業(yè)領(lǐng)域的 需求本質(zhì)，就是專門的建模專家也不例外。
既然需求是多變而且復(fù)雜的，所以，就不能使用“堵”式方法對(duì)其進(jìn)行控制和管理，只能順勢(shì)而為，通過(guò)靈活多變的 以及迭代反復(fù)的方式逐步抓住需求，并且作為需求的實(shí)現(xiàn)軟件系統(tǒng)必須能夠迅速應(yīng)對(duì)需求變化，需求變化有多快，軟件 變化就有多快。
因此，對(duì)于多變的需求，我們的解決之道是：引入靈活多變的架構(gòu)，面向?qū)ο驩O架構(gòu)正是應(yīng)對(duì)多變需求而生，強(qiáng)調(diào)軟件的可維護(hù)性 和拓展性，OO可能不是最好方式，但是目前是最合適的；對(duì)于復(fù)雜的需求，我們的解決之道是：委派專門的建模專家跟蹤理解需求， 在需求和需求實(shí)現(xiàn)之間搭建橋梁，項(xiàng)目方法上采取多次迭代的敏捷軟件開發(fā)方式，逐步了解學(xué)習(xí)掌握需求。
在這里稍微說(shuō)明一下，很多人總是將軟件和數(shù)學(xué)、管理、財(cái)務(wù)混為一談，其實(shí)軟件本身就是一門獨(dú)立的專業(yè)，是為 數(shù)學(xué)、管理。財(cái)務(wù)等專業(yè)領(lǐng)域服務(wù)的，不能期望軟件人員也是其他領(lǐng)域?qū)I(yè)人員，可是在中國(guó)現(xiàn)實(shí)中，很多人總是 無(wú)法分辨，例如某局長(zhǎng)將整個(gè)機(jī)關(guān)考核信息化的任務(wù)交給電腦中心，這就是將考核管理專業(yè)和軟件專業(yè)混同的例子， 在考核管理和軟件之間需要一個(gè)領(lǐng)域建模專家，由他來(lái)理解或者設(shè)計(jì)考核管理體系，然后通過(guò)模型，表達(dá)成 軟件人員能夠看懂的符號(hào)，軟件人員通過(guò)模型了解領(lǐng)域。
曾經(jīng)有需求專家呼吁：最好將需求給所有軟件人員都了解，需求專家和一般軟件人員一起工作，這些想法的本質(zhì)是 好的，但是不可能實(shí)現(xiàn)的，不可能每個(gè)軟件人員不但了解軟件架構(gòu)和OO思想；還能夠掌握另外一個(gè)專業(yè)領(lǐng)域的艱深知識(shí)， 所以，現(xiàn)在我們提出：將領(lǐng)域?qū)＜医⒌慕y(tǒng)一領(lǐng)域模型讓所有軟件人員都了解，讓一般軟件人員圍繞領(lǐng)域模型工作，這樣 的方式才切實(shí)可行。
需求分析方法演變
歷史上，對(duì)需求分析方法可以說(shuō)經(jīng)過(guò)三個(gè)階段：
第一階段：圍繞數(shù)據(jù)庫(kù)的驅(qū)動(dòng)的分析設(shè)計(jì)，新軟件項(xiàng)目總是從設(shè)計(jì)數(shù)據(jù)庫(kù)及其字段開始。這個(gè)階段特征就是圍繞數(shù)據(jù)庫(kù)編程，典型的是 DBase/Foxpro，以及后來(lái)的Delphi/VB技術(shù)。
這種圍繞數(shù)據(jù)庫(kù)分析設(shè)計(jì)的缺點(diǎn)非常明顯：首先，不能迅速有效全面認(rèn)識(shí)反映需求，世界不只是由簡(jiǎn)單的關(guān)系數(shù)據(jù)組成，而且 使用關(guān)系數(shù)據(jù)來(lái)反映現(xiàn)實(shí)需求，不符合人類自然思維（OO才是），是一種扭曲的分析方法，特別對(duì)于初學(xué)者，他們接受數(shù)據(jù)庫(kù)分析方法的難度反而可能會(huì)大于OO分析方法，現(xiàn)在很多職業(yè)學(xué)校和社會(huì)培訓(xùn)，基礎(chǔ)課程從數(shù)據(jù)庫(kù)開始，從某種程度上，是歷史倒退， 嚴(yán)重阻礙中國(guó)軟件發(fā)展的進(jìn)程。
圍繞數(shù)據(jù)庫(kù)分析極其容易導(dǎo)致過(guò)程化設(shè)計(jì)編程，圍繞數(shù)據(jù)分析和過(guò)程化編程是一對(duì)惡魔，數(shù)據(jù)庫(kù)結(jié)構(gòu)確立后，就讓普通程序員寫SQL 語(yǔ)句，SQL語(yǔ)句執(zhí)行有明顯的先后順序，在這樣順序過(guò)程編程思維中，OO思維就難以生存。長(zhǎng)此以往，成為習(xí)慣后，就很難改變到 OO設(shè)計(jì)上，所以，傳統(tǒng)編程經(jīng)驗(yàn)越豐富，轉(zhuǎn)變到OO設(shè)計(jì)就越難。
在運(yùn)行性能方面：圍繞數(shù)據(jù)庫(kù)分析設(shè)計(jì)容易導(dǎo)致軟件運(yùn)行時(shí)負(fù)載集中在數(shù)據(jù)庫(kù)端，系統(tǒng)性能難于擴(kuò)展（走上集中式、昂貴的、高風(fēng)險(xiǎn)的大型機(jī)模式）， 閑置了中間件J2EE服務(wù)器分布式集群處理能力，就是使用了集群，也分擔(dān)不了負(fù)載。
最后，我們必須認(rèn)識(shí)到：對(duì)象和關(guān)系數(shù)據(jù)庫(kù)存在阻抗，本身是矛盾競(jìng)爭(zhēng)的，他們是兩種分析看待需求的流派，可以說(shuō)是水火不容， 要么你采取數(shù)據(jù)庫(kù)分析設(shè)計(jì)以及過(guò)程化編程，要么完全采取OO，現(xiàn)在使用.NET和Java這樣OO語(yǔ)言的人很多，但是70%左右都是使用OO語(yǔ)言
編寫傳統(tǒng)過(guò)程化系統(tǒng)，在Java中這樣做，會(huì)有極差性能；而這種現(xiàn)象在.NET中又極容易得到縱容，.NET是一個(gè)系列陣營(yíng)，正如Windows系列一樣， 當(dāng)你和別人說(shuō)，你在使用Windows，別人可能覺(jué)得你沒(méi)有落后時(shí)代，但是他們哪里知道你在使用Windows 3.1呢？
第二階段：面向?qū)ο蟮姆治鲈O(shè)計(jì)方法誕生后，有了專門的分析和設(shè)計(jì)階段之分，我們使用UML符號(hào)來(lái)表達(dá)分析設(shè)計(jì)思想，分析設(shè)計(jì)進(jìn)入了一個(gè)相對(duì)更高的層次，擁有了自己一套科學(xué)且藝術(shù)的方法論。但是有一個(gè)致命缺點(diǎn)：分析階段和設(shè)計(jì)階段是斷裂的，互相不能很好銜接，為什么？
首先，我們看看分析人員和設(shè)計(jì)人員在職責(zé)重點(diǎn)工作是什么？
分析人員的職責(zé)：是負(fù)責(zé)從需求領(lǐng)域中收集基本概念。而設(shè)計(jì)人員的職責(zé)：必須指明一組能北項(xiàng)目中適應(yīng)編程工具構(gòu)造的組件，這些組件必須能夠在目標(biāo)環(huán)境中有效執(zhí)行，并能夠正確解決應(yīng)用程序出現(xiàn)的問(wèn)題 兩個(gè)階段兩者目標(biāo)不一致，分析人員只管需求分析，至于是否適合設(shè)計(jì)，或者能夠?qū)С鲞m宜設(shè)計(jì)的分析結(jié)果，這個(gè)尺度很難衡量和把握；
而設(shè)計(jì)人員因?yàn)檎疹櫞a可運(yùn)行，因此，經(jīng)?？赡軙?huì)抱怨分析員給出的結(jié)果過(guò)于粗糙，不適合設(shè)計(jì)，這樣分析設(shè)計(jì)兩個(gè)階段就導(dǎo)致分裂，項(xiàng)目失敗。
在這個(gè)階段，雖然有UML幫助，但是UML不是思想，打個(gè)比喻：會(huì)CAD的繪圖員就是建筑師嗎？很顯然，UML就是CAD圖符號(hào)，UML不等于分析設(shè)計(jì)思想。 所以，有人說(shuō)UML不是銀彈，這些就象說(shuō)中醫(yī)不是科學(xué)一樣繞人（中醫(yī)就不是西醫(yī)，當(dāng)然就不是科學(xué)）。
第三階段：融合了分析階段和設(shè)計(jì)階段的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（Evans: DDD）。2004年Eric Evans 發(fā)表Domain-Driven Design –Tackling Complexity in the Heart of Software （領(lǐng)域驅(qū)動(dòng)設(shè)計(jì) ）簡(jiǎn)稱Evans DDD， 領(lǐng)域建模是一種藝術(shù)的技術(shù)，它是用來(lái)解決復(fù)雜軟件快速應(yīng)付變化的解決之道，所以，從Evans DDD通篇文章中，你找不到科學(xué)象征的定理和公式，當(dāng)然如果 你試圖尋找這樣尋找，你也就陷入了“中醫(yī)是不是科學(xué)”怪圈了。
Evans DDD拋棄了分裂分析模型與設(shè)計(jì)的做法，使用單一的模型來(lái)滿足這兩方面的要求。這就是領(lǐng)域模型。 單一的領(lǐng)域模型同時(shí)滿足分析原型和軟件設(shè)計(jì) ，如果一個(gè)模型實(shí)現(xiàn)時(shí)不實(shí)用，重新尋找新模型。如果模型沒(méi)有忠實(shí)表達(dá)領(lǐng)域關(guān)鍵概念時(shí)，也必須重新尋找新的模型。 建模和設(shè)計(jì)成為單個(gè)迭代循環(huán)。將領(lǐng)域模型和設(shè)計(jì)緊密聯(lián)系。因此，建模專家必須懂設(shè)計(jì)。
領(lǐng)域建模的重要性
如果你說(shuō)一個(gè)軟件開發(fā)需要經(jīng)過(guò)需求、分析和設(shè)計(jì)三個(gè)階段的話，那么可能反映你的思想已經(jīng)落伍，軟件開發(fā)現(xiàn)在是 經(jīng)過(guò)需求、建模階段，混合了分析和設(shè)計(jì)階段，可以更激進(jìn)地說(shuō)：我們國(guó)家的系統(tǒng)分析員和系統(tǒng)設(shè)計(jì)員考試也許應(yīng)該合并了， 合并成建模專家的考試，否則，這些都是中國(guó)軟件落后世界十年的證據(jù)，可悲的是：我們自己可能都不知道。
Evans DDD可以說(shuō)是近期與SOA相提并論的兩大重要技術(shù)思想，SOA是著重于軟件集成方面；而EvansDDD才是著重我們軟件開發(fā)上， 在大部分情況下，軟件開發(fā)重要程度不亞于軟件集成，但是因?yàn)檐浖_發(fā)方面開源力量沖擊，軟件集成上工業(yè)廠商利潤(rùn)最高， 所以，工業(yè)廠商在SOA叫得最響，我們參加得各種會(huì)議幾乎都是SOA，當(dāng)心被誤導(dǎo)，工業(yè)廠商從來(lái)不會(huì)告訴你事實(shí)得爭(zhēng)相。
沒(méi)有面向?qū)ο蟮姆治鲈O(shè)計(jì)，哪里面向?qū)ο蟮臉?gòu)件或組件？過(guò)去經(jīng)驗(yàn)不是證明：我們使用大量的構(gòu)件組件，卻在編制面向過(guò)程的體系？
以EJB2為例子，在EJB2過(guò)去大部分系統(tǒng)中，我們常常以數(shù)據(jù)庫(kù)為中心，實(shí)體Bean因?yàn)樘厥饧夹g(shù)原因，僵硬一塊，變成數(shù)據(jù)庫(kù) 的代名詞，我們圍繞實(shí)體Bean編制出大量的值對(duì)象Vale Obejct，或稱為DTO（Data Transfer Object），在這樣系統(tǒng)中，從對(duì)象 的名稱也可以看出，對(duì)象是為數(shù)據(jù)服務(wù)的，對(duì)象從屬于數(shù)據(jù)庫(kù)的。
現(xiàn)在，要徹底改變過(guò)來(lái)，OO就是以對(duì)象為主，數(shù)據(jù)庫(kù)是從屬對(duì)象設(shè)計(jì)的，如果說(shuō)EJB2的實(shí)體bean技術(shù)讓你不得不走上傳統(tǒng)過(guò)程化編程歧路，那么 EJB3已經(jīng)更正了實(shí)體Bean設(shè)計(jì)缺陷，從EJB發(fā)展可以看到一個(gè)側(cè)面：工業(yè)廠商更多關(guān)心的是功能，而不是設(shè)計(jì)？
只有誰(shuí)才真正關(guān)心你的軟件設(shè)計(jì)和代碼質(zhì)量？只有你自己。我不是提倡都不要參加工業(yè)廠商的會(huì)議，而是需要每個(gè)人冷靜想想： 到底誰(shuí)是自己代碼的主人？
領(lǐng)域建模屬于與具體.NET或Java技術(shù)無(wú)關(guān)的設(shè)計(jì)思想，有人總是說(shuō)：.NET比Java簡(jiǎn)單，其實(shí)這又是一個(gè)大誤區(qū)，如果都達(dá)到同樣設(shè)計(jì)水準(zhǔn)，無(wú)論使用.NET或Java，都需要付出同樣的努力；那為什么有人覺(jué)得.NET簡(jiǎn)單，那是因?yàn)樵O(shè)計(jì)要求降低了，參見這篇.NET的DDD文章。
分層架構(gòu)
分層架構(gòu)是現(xiàn)代OO軟件企業(yè)系統(tǒng)的基本架構(gòu)，只有分層才能達(dá)到良好的可拓展性和維護(hù)性?；救龑樱罕憩F(xiàn)層、業(yè)務(wù)層和持久層 ;J2EE中表現(xiàn)層和持久層有成熟框架支持，應(yīng)用重點(diǎn)在業(yè)務(wù)層。
業(yè)務(wù)層根據(jù)Evans DDD，可以再細(xì)分為應(yīng)用層和領(lǐng)域?qū)觾煞N，在業(yè)務(wù)層設(shè)計(jì)編碼中，大量應(yīng)用OO設(shè)計(jì)原則和設(shè)計(jì)模式。領(lǐng)域?qū)佣x：負(fù)責(zé)表達(dá)業(yè)務(wù)領(lǐng)域概念、業(yè)務(wù)狀態(tài)以及業(yè)務(wù)規(guī)則，是整個(gè)業(yè)務(wù)軟件核心和重點(diǎn)。 應(yīng)用層定義：負(fù)責(zé)完成功能，并且協(xié)調(diào)豐富的領(lǐng)域?qū)ο髞?lái)實(shí)現(xiàn)功能，不能包括業(yè)務(wù)規(guī)則，無(wú)業(yè)務(wù)狀態(tài)；
每個(gè)層都是內(nèi)聚的，并且只依賴它的下層，為了實(shí)現(xiàn)各層的最大解耦，IOC/DI容器是當(dāng)前Java業(yè)務(wù)層的最好選擇 。
沒(méi)有分層架構(gòu)的快速開發(fā)基本是旁門左道，不如返回Foxpro和Delphi/VB兩層時(shí)代。將本屬于業(yè)務(wù)層的邏輯交由表現(xiàn)層來(lái)處理的快速UI方式也是一種旁門左道?？焖匍_發(fā)必須基于良好的質(zhì)量，雖然良好的分層架構(gòu)帶來(lái)開發(fā)效率的降低，但是這些也是可以有方法解決。
建模與項(xiàng)目管理
在我們大多數(shù)從軟件項(xiàng)目管理上尋找軟件永恒解決之道時(shí)，他們可能沒(méi)有意識(shí)到又在范“緣木求魚”老毛病了， 打個(gè)比喻很容易明白這個(gè)道理：冷兵器時(shí)代（也就是火槍沒(méi)有沒(méi)有發(fā)明之前），各種排兵布陣可能在作戰(zhàn)指揮時(shí) 很有效；但是到了火器時(shí)代，所有的過(guò)去作戰(zhàn)方式就落伍了；當(dāng)然到了現(xiàn)在信息化戰(zhàn)爭(zhēng)時(shí)代，更是天壤之別。
Evans DDD領(lǐng)域驅(qū)動(dòng)建模的誕生，對(duì)過(guò)去傳統(tǒng)的項(xiàng)目管理都提出挑戰(zhàn)，當(dāng)我們還在爭(zhēng)論RUP好還是敏捷好的時(shí)候， 誰(shuí)會(huì)想到我們應(yīng)該采取圍繞統(tǒng)一領(lǐng)域模型的迭代驅(qū)動(dòng)開發(fā)呢？
有人可能還在疑惑？我接到一個(gè)大項(xiàng)目，那么我的建模和架構(gòu)設(shè)計(jì)時(shí)間應(yīng)該是5個(gè)月還是5年呢？當(dāng)然應(yīng)該回答他：都不行，需求是多變且復(fù)雜的，計(jì)劃趕不上變化，現(xiàn)在就應(yīng)該開始DDD建模。
(以上文字源自板橋本人的第四屆中國(guó)軟件技術(shù)大會(huì)“領(lǐng)域設(shè)計(jì)建模”演講稿 )
聯(lián)系客服
