過去，當我們面對一個新的業(yè)務需求時，我們總是從先建立數(shù)據(jù)表結(jié)構(gòu)開始，這種面向數(shù)據(jù)表的分析設計方法已經(jīng)逐步被面向模型的分析設計方法替代。

　　使用數(shù)據(jù)表分析需求，無法涵括項目的全部需求設計，例如系統(tǒng)的狀態(tài)無法統(tǒng)一設計，最終導致每個程序員都可以直接操控系統(tǒng)的狀態(tài)，導致整個系統(tǒng)狀態(tài)運行混亂；使用數(shù)據(jù)表分析，還非常容易將實體表和關系混合在一起，造成分析者視覺混亂，無法正確分析出系統(tǒng)的真正基本實體；使用數(shù)據(jù)表分析還會導致軟件系統(tǒng)以數(shù)據(jù)庫為中心的編碼架構(gòu)，進而產(chǎn)生傳統(tǒng)過程化編程風格，難于維護和拓展，甚至性能低下，將系統(tǒng)負載都集中在數(shù)據(jù)庫服務器端，走上傳統(tǒng)的大型機集中式計算模式，而不是分布式計算模式；使用數(shù)據(jù)表分析還會喪失多層結(jié)構(gòu)引以為豪的中間層，回復到過去的兩層結(jié)構(gòu)，更談不上設計模式應用了。

　　領域建模提倡的面向模型的分析設計方法，系統(tǒng)一開始我們就首先確立領域模型Domain Model，以及它們之間的關系，進而可以交由程序員分別實現(xiàn)表現(xiàn)層、業(yè)務服務層和持久層，通過使用Jdon Framework（以下簡稱JF）等模型驅(qū)動框架，結(jié)合FDD等模型驅(qū)動的工程方法，從而正確無誤地、且快速高質(zhì)量地完成一個軟件開發(fā)過程。

　　下面我們從分析、設計和開發(fā)幾個環(huán)節(jié)說明一下時下流行的最新軟件開發(fā)模式：

MDA步驟

• Models　建模

• Abstraction　抽象細化。落實細節(jié)。

• Platform　平臺架構(gòu)選擇，J2EE還是.NET，J2EE中選擇如何架構(gòu)，下面案例我們是選擇Struts+JdonFramework+Hibernate架構(gòu)平臺，所以，目前JF屬于整個模型驅(qū)動開發(fā)環(huán)節(jié)中Platform部分。

• Model transformation 模型傳遞，將模型設計傳遞為java的類代碼。

• The MDA value proposition

　　DSM(Domain-Specific Modeling)是在上述MDA基礎上，加強平臺定義映射和模型映射靈活性和自住性，不象MDA工具，一出廠這個工具就確定死了平臺和技術細節(jié)。

　　MDA工具和DSM將模型驅(qū)動軟件開發(fā)過程自動化，但是實際中，更多人工手工介入，下面展示這個過程。

論壇系統(tǒng)的模型驅(qū)動開發(fā)

　　首先，我們使用UML用例圖來完整清晰地表達一下一個新系統(tǒng)的需求，從而才能夠保證正確地建模。

　　比如一個論壇的簡單需求如下：

　　從這個需求中，我們需要發(fā)現(xiàn)那些有一定內(nèi)容的實體對象，Actor1表示用戶角色，用例圖可以說用來表示“什么人做什么事情”，我們只要把“事情”抽象出來，作為實體對象，可能就是我們的領域模型（Domain Model），上圖中發(fā)言用例實際可理解為用戶發(fā)表言論，按照“什么人做什么事情”分析方法，實際是“用戶”（什么人）?。　鞍l(fā)表”（做）　＋　“言論”（事情），我們可以總結(jié)這里的“事情“是”言論“，”言論“作為實體對象，也就是Message（消息　帖子）。

　　"發(fā)言"實際就是模型Message的創(chuàng)建，有創(chuàng)建必有修改，增刪改查CRUD功能必會有。

　　“回復”實際也是Message對象的創(chuàng)建，只不過有父子關系罷了。使用同樣的方法可以從“瀏覽論壇”中分析出　Forum（論壇）這個領域?qū)ο蟆?/p>

　　Forum和Message之間類關系應該是1:N的關聯(lián)，我們使用如下類圖表達我們的模型：

　　Forum和Message提取過程是建模Modeling過程，有了模型類圖；通過Abstraction細化過程，有了模型初始化以及細化。

　　通過Model transformation 過程，有了的模型類的java代碼：

　　有了這兩個模型類，圍繞模型的業(yè)務服務接口也便誕生，如圍繞Forum的ForumService和圍繞Message的MessageService：

　　自此，我們有了領域模型類和業(yè)務服務類，使用過JF的人就會發(fā)現(xiàn)，Jdon框架也正是需要這兩種類的確立，下面就可以使用JF快速完成Forum和Message的增刪改查以及批量查詢兩個基本功能了，見Step By Step 開發(fā)JdonFramework應用主要步驟。

倉庫系統(tǒng)的模型驅(qū)動開發(fā)

　　下面再以ERP中倉庫管理系統(tǒng)開發(fā)為例簡要說明模型驅(qū)動開發(fā)過程，倉庫簡單用例如下：

　　我們再以“什么人做什么事情”來分析倉庫的用例功能，“成品入庫”如何分解為“什么人做什么事情”？我們可以這樣理解：倉庫員（什么人）+ 錄入(做) + 庫單（什么事情），這樣，我們提煉出實體對象“庫單”；進而從“商品資料維護”功能可以提煉出“商品”模型。

　　“成品入庫”實際是“庫單”的新增，必然有“庫單”的增刪改查CRUD功能需求。

　　我們建立兩個模型的類圖如下：

　　有了類圖，通過模型細化和落實，我們可以有Product等三個模型代碼類，進而圍繞這三個模型的業(yè)務Service接口也會產(chǎn)生，通過使用JF的CRUD和批量查詢，我們可以快速完成倉庫系統(tǒng)的基本功能。見Step By Step 開發(fā)JdonFramework應用主要步驟。

總結(jié)

　　以上通過兩個簡單案例說明領域模型的簡單提煉過程，當然實際項目中，遠沒有如此簡單，而且也不只是模型的CRUD功能，但是我們可以通過四色圖分析方法來抓住復雜系統(tǒng)中的模型和業(yè)務服務功能，一般四色圖的MI是使用業(yè)務服務Service實現(xiàn)；Description是一個域模型。

　　JiveJdon3.0是按照模型驅(qū)動架構(gòu)思路開發(fā)的一個復雜軟件系統(tǒng)。

　　如圖所示：模型和業(yè)務服務是在一個系統(tǒng)架構(gòu)之前建立的，所以沒有面向模型的領域建模分析方法，就沒有Domain Model，就沒有模型對象，就沒有中間業(yè)務層，沒有中間層，就沒有設計模式的使用空間。同時，沒有模型對象，就沒有表現(xiàn)層的邊界對象（如Struts的ActionForm）;也就沒有模型對象的持久化（使用Hibernate等O/R Mapping工具），特別是在持久層使用Hibernate，最后搞個值對象VO作為數(shù)據(jù)表數(shù)據(jù)的存貯對象，很明顯，對象屈從于數(shù)據(jù)表了，又在搞面向數(shù)據(jù)表的分析設計了，你這是在將汽車當自行車推了，這種對象屈從于數(shù)據(jù)表會造成如下圖左邊的亂糟糟結(jié)構(gòu)，而右圖則是因為強調(diào)了模型的統(tǒng)帥和領導地位，整個系統(tǒng)變得井井有條：