熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> Java高級技術 >> 正文

領域模型驅動設計(DDD)之模型提煉

2013-11-23 19:54:46  來源: Java高級技術 
    當Java世界提供的可選擇性框架平台越來越多時我們可能被平台架構所深深困擾而無暇顧及軟件的真正核心業務建模其實業務領域建模同樣是一個比平台架構更復雜更需要學習的新的領域

  相反在實踐中我們技術人員在經過冗長的平台架構學習和實踐後就匆忙開始項目開發這時是什麼指導他們進行軟件業務實現呢?大部分可能是依賴數據庫建模甚至是復雜冗長的數據庫存儲過程設計這些已經開始走向面向對象分析設計的反方向走上了一條錯誤的軟件開發方向最終開發出緩慢的經常當機的Java企業系統

  如果你沒有恰當的OO設計思想Java就會用性能懲罰你這可能是Java世界的一個潛規則

  那麼一個正確的OOA/OOD/OOP步驟是什麼呢?目前圍繞模型驅動設計(MDD)的設計思想成為主流思想MDA更是在MDD基礎上提升和升華下面讓我們首先了解如何使用領域驅動設計思想來分析設計一個軟件系統

  當我們不再對一個新系統進行數據庫提煉時取而代之的時面向對象的模型提煉我們必須大刀闊斧地對業務領域進行細分將一個復雜的業務領域劃分為多個小的子領域同時還必須分清重點和次要部分抓住核心領域概念實現重點突破

  核心領域模型

  精簡模型找出核心領域將業務需求中最有價值的概念體現出來讓核心變精要這實際就是一個使復雜問題變簡單的過程也是對我們軟件設計人員真正能力的考驗

  核心領域模型不是輕易能夠發現特別是他處於一個紛亂復雜的眾多領域模型結構中時核心模型通常是我們某個子領域關注的重點例如訂單模型是訂單管理領域的核心消息模型是論壇或消息領域系統的核心

  目前分析領域有很多模式來幫助我們來提煉核心模型例如四色原型Martin Fowler 的分析模式等例如MF的分析模式(Analysis Patterns)中的記帳模型就是不僅僅用來記錄賬目數值而且可以記錄和控制賬目的每一次修改而四色原型則是一種高於分析模式的一種原型基本模式下面是本人根據四色原型提煉的核心領域模型概念

  一般情況下在企業應用中核心模型總是在其周圍圍繞一些所謂的衛星這實際上也是來自四色原型的一個推論核心模型和其衛星的類圖如下

  core model

  根據Eric Evans在其領域驅動設計一書中定義領域模型劃分為實體和值對象兩種實體模型是指業務領域中具有獨立屬性的對象而值對象則可能是一種Description或狀態或規則只要有實體對象就可能存在實體的狀態狀態跟蹤有時成為一個業務領域使用計算機軟件的首要跟蹤但是數據庫不是對象狀態的唯一表達方式只是一種存儲方式(見狀態對象數據庫的替代者)

  圖中實體核心對象大部分可能有一種類型例如核心模型是產品那麼存在產品目錄核心模型是消息就存在消息類型核心模型是信息總存在信息類別我們總是使用分類方式來管理業務領域的信息有時類別甚至復雜到樹形結構

  核心實體模型有時會有一個:N關聯的子實體一般可能表達實體的細節例如核心模型是訂單那麼存在訂單條目這樣一個細節一個訂單中可能有多個訂單條目如果核心模型是信息那麼存在該信息的多個回復或評論這樣的關聯一般存在多個業務領域中

  模型界面實現

  原來我們以為分析設計階段無需了解實現細節分析人員只要悶頭做分析UML圖而無需顧及如何具體實現其實這是一個誤區

  Eric Evans在其領域驅動設計一書中認為分析人員負責從領域中收集基本概念 設計則必須指明一組適應編程工具構造的組件以及這些組件必須能夠在目標環境中有效執行模型驅動設計(ModelDriven Design)拋棄了分裂分析模型與設計的做法使用單一的模型來滿足這兩方面的要求因此對於核心模型必須掌握了解其實現細節

  從另外一個方面來說中國的客戶總是從界面設計來表達他們的意圖(如果中國客戶能夠使用Use Case等UML圖來表達他們概念真是不可想象)例如客戶會說我希望有一個界面讓我將訂單數據輸入然後能夠查詢符合查詢條件的訂單因此我們的核心模型至少能夠順利地映射到界面實現相反這個客戶有這樣訂單界面要求但是你沒有提供一個與之適應的核心實體模型界面實現將變得復雜甚至走很多彎路誕生不少DTO垃圾對象

  以JdonFramework框架實現為例子框架提供了圍繞核心模型的新增刪除修改查詢(CRUD)功能以及批量功能的快速實現尤其CRUD功能實現前提是必須提煉出核心模型從而其界面設計流程就能通過配置立即實現這樣一步到位實現領域模型到界面的過渡可以將我們設計核心模型和客戶要求的界面需求能夠做到完整的統一

  開源JdonFramework下載包中message案例實際就是上述核心模型圖的一種實現項目更復雜的項目可以認為是核心模型的重疊和反復使用(從原理上講核心模型是四色原型的體現而四色原型被認為是大部分企業系統的基本組成元素見[book][UML][Peter Coad]Java Modeling in Color with UML)

  核心模型的選擇

  實際項目中會存在多個核心模型的重疊和覆蓋使用主要取決於你的領域關注重點

  例如當客戶和我們說要做一個旅游網站時我們必須充分了解需求它的軟件系統重點是哪些功能如果當他首先說我需要一個酒店設備的查詢系統因為他的客戶對酒店設備非常關注那麼我們可能認為酒店設備是這個領域模型的核心酒店設備如果他又進行描述我需要一個界面客戶在輸入酒店資料時選擇多個酒店設備那麼在這樣一個關注領域核心模型實際是酒店而酒店設備可能成為酒店的一個特征實體屬性甚至是值對象了

  以進銷存系統為例子在采購系統中采購單是一個核心實體模型而原材料是一種輔助實體模型在庫存系統中入出庫單是一個核心實體模型原材料或成品代表的是一個庫存物品概念模型當需要庫存報表查詢輸出可以立即計算出來或將結果緩存起來緩存起來的結果其實是庫存物品對象的狀態可以使用值對象來實現

  核心模型的精練

  當核心模型被定位和確定後相當於我們抓住領域本質這時我們可以使用面向對象的概念對模型進行精練細化實際就是明確對象的屬性確定模型對象的邊界通過反復重構結合GoF等設計模式使得我們得模型准確反映本質從而實現模型的靈活性設計所有這些都是數據表驅動設計所不能實現的那你還抱著數據庫建模干什麼呢?


From:http://tw.wingwit.com/Article/program/Java/gj/201311/27660.html
    推薦文章
    Copyright © 2005-2013 電腦知識網 Computer Knowledge   All rights reserved.