過去，當我們面對一個新的業務需求時，我們總是從先建立數據表結構開始，這種面向數據表的分析設計方法已經逐步被面向模型的分析設計方法替代。
使用數據表分析需求，無法涵括項目的全部需求設計，例如系統的狀態無法統一設計，最終導致每個程序員都可以直接操控系統的狀態，導致整個系統狀態運行混亂；使用數據表分析，還非常容易將實體表和關系混合在一起，造成分析者視覺混亂，無法正確分析出系統的真正基本實體；使用數據表分析還會導致軟件系統以數據庫為中心的編碼架構，進而產生傳統過程化編程風格，難于維護和拓展，甚至性能低下，將系統負載都集中在數據庫服務器端，走上傳統的大型機集中式計算模式，而不是分布式計算模式；使用數據表分析還會喪失多層結構引以為豪的中間層，回復到過去的兩層結構，更談不上設計模式應用了。
領域建模提倡的面向模型的分析設計方法，系統一開始我們就首先確立領域模型Domain Model，以及它們之間的關系，進而可以交由程序員分別實現表現層、業務服務層和持久層，通過使用Jdon Framework（以下簡稱JF）等模型驅動框架，結合FDD等模型驅動的工程方法，從而正確無誤地、且快速高質量地完成一個軟件開發過程。
下面我們從分析、設計和開發幾個環節說明一下時下流行的最新軟件開發模式：
MDA步驟
-
Models 建模
-
Abstraction 抽象細化。落實細節。
-
Platform 平臺架構選擇，J2EE還是.NET，J2EE中選擇如何架構，下面案例我們是選擇Struts+JdonFramework+Hibernate架構平臺，所以，目前JF屬于整個模型驅動開發環節中Platform部分。
-
Model transformation 模型傳遞，將模型設計傳遞為java的類代碼。
-
The MDA value proposition
DSM(Domain-Specific Modeling)是在上述MDA基礎上，加強平臺定義映射和模型映射靈活性和自住性，不象MDA工具，一出廠這個工具就確定死了平臺和技術細節。
MDA工具和DSM將模型驅動軟件開發過程自動化，但是實際中，更多人工手工介入，下面展示這個過程。
論壇系統的模型驅動開發
首先，我們使用UML用例圖來完整清晰地表達一下一個新系統的需求，從而才能夠保證正確地建模。
比如一個論壇的簡單需求如下：
從這個需求中，我們需要發現那些有一定內容的實體對象，Actor1表示用戶角色，用例圖可以說用來表示“什么人做什么事情”，我們只要把“事情”抽象出來，作為實體對象，可能就是我們的領域模型（Domain Model），上圖中發言用例實際可理解為用戶發表言論，按照“什么人做什么事情”分析方法，實際是“用戶”（什么人）�。 鞍l表”（做）�。 把哉摗保ㄊ虑椋�，我們可以總結這里的“事情“是”言論“，”言論“作為實體對象，也就是Message（消息 帖子）。
"發言"實際就是模型Message的創建，有創建必有修改，增刪改查CRUD功能必會有。
“回復”實際也是Message對象的創建，只不過有父子關系罷了。使用同樣的方法可以從“瀏覽論壇”中分析出 Forum（論壇）這個領域對象。
Forum和Message之間類關系應該是1:N的關聯，我們使用如下類圖表達我們的模型：
Forum和Message提取過程是建模Modeling過程，有了模型類圖；通過Abstraction細化過程，有了模型初始化以及細化。
通過Model transformation 過程，有了的模型類的java代碼：
|
package sample.forum.model public class Forum{ private String forumId; private String name; private Collection messages; //表示和Message的1:N關系（one-to-many） ..... }
package sample.forum.model public class Message{ private String messageId; private String name; private Forum forum; //表示和Forum的N:1關系（many-to-one） ..... } |
有了這兩個模型類，圍繞模型的業務服務接口也便誕生，如圍繞Forum的ForumService和圍繞Message的MessageService：
|
package sample.forum.service public interface ForumService{ void createForum(EventModel em); Forum getForum(String forumId); ..... }
|
自此，我們有了領域模型類和業務服務類，使用過JF的人就會發現，Jdon框架也正是需要這兩種類的確立，下面就可以使用JF快速完成Forum和Message的增刪改查以及批量查詢兩個基本功能了，見Step By Step 開發JdonFramework應用主要步驟。
倉庫系統的模型驅動開發
下面再以ERP中倉庫管理系統開發為例簡要說明模型驅動開發過程，倉庫簡單用例如下：
我們再以“什么人做什么事情”來分析倉庫的用例功能，“成品入庫”如何分解為“什么人做什么事情”？我們可以這樣理解：倉庫員（什么人）+ 錄入(做) + 庫單（什么事情），這樣，我們提煉出實體對象“庫單”；進而從“商品資料維護”功能可以提煉出“商品”模型。
“成品入庫”實際是“庫單”的新增，必然有“庫單”的增刪改查CRUD功能需求。
我們建立兩個模型的類圖如下：
有了類圖，通過模型細化和落實，我們可以有Product等三個模型代碼類，進而圍繞這三個模型的業務Service接口也會產生，通過使用JF的CRUD和批量查詢，我們可以快速完成倉庫系統的基本功能。見Step By Step 開發JdonFramework應用主要步驟。
總結
以上通過兩個簡單案例說明領域模型的簡單提煉過程，當然實際項目中，遠沒有如此簡單，而且也不只是模型的CRUD功能，但是我們可以通過四色圖分析方法來抓住復雜系統中的模型和業務服務功能，一般四色圖的MI是使用業務服務Service實現；Description是一個域模型。
JiveJdon3.0是按照模型驅動架構思路開發的一個復雜軟件系統。
如圖所示：模型和業務服務是在一個系統架構之前建立的，所以沒有面向模型的領域建模分析方法，就沒有Domain Model，就沒有模型對象，就沒有中間業務層，沒有中間層，就沒有設計模式的使用空間。同時，沒有模型對象，就沒有表現層的邊界對象（如Struts的ActionForm）;也就沒有模型對象的持久化（使用Hibernate等O/R Mapping工具），特別是在持久層使用Hibernate，最后搞個值對象VO作為數據表數據的存貯對象，很明顯，對象屈從于數據表了，又在搞面向數據表的分析設計了，你這是在將汽車當自行車推了，這種對象屈從于數據表會造成如下圖左邊的亂糟糟結構，而右圖則是因為強調了模型的統帥和領導地位，整個系統變得井井有條：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
