相反 在實踐中 我們技術人員在經過冗長的平臺架構學習和實踐後 就匆忙開始項目開發 這時是什麽指導他們進行軟件業務實現呢？大部分可能是依賴數據庫建模 甚至是復雜冗長的數據庫存儲過程設計 這些已經開始走向面向對象分析設計的反方向 走上了壹條錯誤的軟件開發方向 最終開發出緩慢的 經常當機的Java企業系統
如果妳沒有恰當的OO設計思想 Java就會用性能懲罰妳 這可能是Java世界的壹個潛規則
那麽 壹個正確的OOA/OOD/OOP步驟是什麽呢？目前圍繞模型驅動設計(MDD)的設計思想成為主流思想 MDA更是在MDD基礎上提升和升華 下面讓我們首先了解 如何使用領域驅動設計思想來分析設計壹個軟件系統
當我們不再對壹個新系統進行數據庫提煉時 取而代之的時面向對象的模型提煉 我們必須大刀闊斧地對業務領域進行細分 將壹個復雜的業務領域劃分為多個小的子領域 同時還必須分清重點和次要部分 抓住核心領域概念 實現重點突破
核心領域模型
精簡模型 找出核心領域 將業務需求中最有價值的概念體現出來 讓核心變精要 這實際就是壹個使復雜問題變簡單的過程 也是對我們軟件設計人員真正能力的考驗
核心領域模型不是輕易能夠發現 特別是他處於壹個紛亂復雜的眾多領域模型結構中時 核心模型通常是我們某個子領域關註的重點 例如訂單模型是訂單管理領域的核心 消息模型是論壇或消息領域系統的核心
目前 分析領域有很多模式來幫助我們來提煉核心模型 例如四色原型 Martin Fowler 的分析模式等 例如MF的 分析模式 (Analysis Patterns)中的記帳模型就是不僅僅用來記錄賬目數值 而且可以記錄和控制賬目的每壹次修改 而四色原型則是壹種高於分析模式的壹種原型基本模式 下面是本人根據四色原型提煉的核心領域模型概念
壹般情況下 在企業應用中 核心模型總是在其周圍圍繞壹些所謂的 衛星 這實際上也是來自四色原型的壹個推論 核心模型和其 衛星 的類圖如下
根據Eric Evans在其 領域驅動設計 壹書中定義 領域模型劃分為實體和值對象兩種 實體模型是指業務領域中具有獨立屬性的對象 而值對象則可能是壹種Description或狀態或規則 只要有實體對象 就可能存在實體的狀態 狀態跟蹤有時成為壹個業務領域使用計算機軟件的首要跟蹤 但是 數據庫不是對象狀態的唯壹表達方式 只是壹種存儲方式(見狀態對象 數據庫的替代者)
圖中 實體核心對象大部分可能有壹種類型 例如核心模型是產品 那麽存在產品目錄 核心模型是消息 就存在消息類型 核心模型是信息 總存在信息類別 我們總是使用分類方式來管理業務領域的信息 有時 類別甚至復雜到樹形結構
核心實體模型有時會有壹個 :N關聯的子實體 壹般可能表達實體的細節 例如 核心模型是訂單 那麽存在訂單條目這樣壹個細節 壹個訂單中可能有多個訂單條目 如果核心模型是信息 那麽存在該信息的多個回復或評論 這樣的關聯壹般存在多個業務領域中
模型界面實現
原來 我們以為分析設計階段無需了解實現細節 分析人員只要悶頭做分析UML圖 而無需顧及如何具體實現 其實這是壹個誤區
Eric Evans在其 領域驅動設計 壹書中認為 分析人員負責從領域中收集基本概念 設計則必須指明壹組適應編程工具構造的組件 以及這些組件必須能夠在目標環境中有效執行 模型驅動設計(Model Driven Design)拋棄了分裂分析模型與設計的做法 使用單壹的模型來滿足這兩方面的要求 因此 對於核心模型必須掌握了解其實現細節
從另外壹個方面來說 中國的客戶總是從界面設計來表達他們的意圖（如果中國客戶能夠使用Use Case等UML圖來表達他們概念真是不可想象） 例如客戶會說 我希望有壹個界面讓我將訂單數據輸入 然後能夠查詢符合查詢條件的訂單 因此 我們的核心模型至少能夠順利地映射到界面實現 相反 這個客戶有這樣訂單界面要求 但是妳沒有提供壹個與之適應的核心實體模型 界面實現將變得復雜 甚至走很多彎路 誕生不少DTO垃圾對象
以JdonFramework框架實現為例子 框架提供了圍繞核心模型的新增刪除修改查詢(CRUD)功能以及批量功能的快速實現 尤其CRUD功能實現前提是必須提煉出核心模型 從而其界面設計流程就能通過配置立即實現 這樣壹步到位實現領域模型到界面的過渡 可以將我們設計核心模型和客戶要求的界面需求能夠做到完整的統壹
開源JdonFramework下載包中message案例實際就是上述核心模型圖的壹種實現項目 更復雜的項目可以認為是核心模型的重疊和反復使用（從原理上講 核心模型是四色原型的體現 而四色原型被認為是大部分企業系統的基本組成元素 見[book][UML][Peter Coad]Java Modeling in Color with UML）
核心模型的選擇
實際項目中 會存在多個核心模型的重疊和覆蓋使用 主要取決於妳的領域關註重點
例如當客戶和我們說要做壹個旅遊網站時 我們必須充分了解需求 它的軟件系統重點是哪些功能 如果當他首先說 我需要壹個酒店設備的查詢系統 因為他的客戶對酒店設備非常關註 那麽我們可能認為酒店設備是這個領域模型的核心 酒店設備 如果他又進行描述 我需要壹個界面 客戶在輸入酒店資料時 選擇多個酒店設備 那麽在這樣壹個關註領域 核心模型實際是酒店 而酒店設備可能成為酒店的壹個特征實體屬性 甚至是值對象了
以進銷存系統為例子 在采購系統中 采購單是壹個核心實體模型 而原材料是壹種輔助實體模型 在庫存系統中 入出庫單是壹個核心實體模型 原材料或成品代表的是壹個庫存物品概念模型 當需要庫存報表查詢輸出 可以立即計算出來 或將結果緩存起來 緩存起來的結果其實是庫存物品對象的狀態 可以使用值對象來實現
核心模型的精練
lishixinzhi/Article/program/Java/gj/201311/27660