當Java世界提供的可選擇性框架平臺越來越多時，我們可能被平臺架構所深深困擾，而無暇顧及軟件的真正核心：業(yè)務建模，其實，業(yè)務領域建模同樣是一個比平臺架構更復雜，更需要學習的新的領域。
相反，在實踐中，我們技術人員在經(jīng)過冗長的平臺架構學習和實踐后，就匆忙開始項目開發(fā)，這時是什么指導他們進行軟件業(yè)務實現(xiàn)呢？大部分可能是依賴數(shù)據(jù)庫建模，甚至是復雜冗長的數(shù)據(jù)庫存儲過程設計，這些已經(jīng)開始走向面向對象分析設計的反方向，走上了一條錯誤的軟件開發(fā)方向，最終開發(fā)出緩慢的、經(jīng)常當機的Java企業(yè)系統(tǒng)。
如果你沒有恰當?shù)腛O設計思想，Java就會用性能懲罰你，這可能是Java世界的一個潛規(guī)則。
那么，一個正確的OOA/OOD/OOP步驟是什么呢？目前圍繞模型驅動設計(MDD)的設計思想成為主流思想，MDA更是在MDD基礎上提升和升華。下面讓我們首先了解，如何使用領域驅動設計思想來分析設計一個軟件系統(tǒng)。
當我們不再對一個新系統(tǒng)進行數(shù)據(jù)庫提煉時，取而代之的時面向對象的模型提煉。我們必須大刀闊斧地對業(yè)務領域進行細分，將一個復雜的業(yè)務領域劃分為多個小的子領域，同時還必須分清重點和次要部分，抓住核心領域概念，實現(xiàn)重點突破。
核心領域模型
精簡模型，找出核心領域，將業(yè)務需求中最有價值的概念體現(xiàn)出來，讓核心變精要，這實際就是一個使復雜問題變簡單的過程，也是對我們軟件設計人員真正能力的考驗。
核心領域模型不是輕易能夠發(fā)現(xiàn)，特別是他處于一個紛亂復雜的眾多領域模型結構中時，核心模型通常是我們某個子領域關注的重點，例如訂單模型是訂單管理領域的核心；消息模型是論壇或消息領域系統(tǒng)的核心。
目前，分析領域有很多模式來幫助我們來提煉核心模型，例如四色原型、Martin Fowler 的分析模式等，例如MF的"分析模式"(Analysis Patterns)中的記帳模型就是不僅僅用來記錄賬目數(shù)值，而且可以記錄和控制賬目的每一次修改。而四色原型則是一種高于分析模式的一種原型基本模式，下面是本人根據(jù)四色原型提煉的核心領域模型概念。
一般情況下，在企業(yè)應用中，核心模型總是在其周圍圍繞一些所謂的“衛(wèi)星”，這實際上也是來自四色原型的一個推論
根據(jù)Eric Evans在其“領域驅動設計”一書中定義，領域模型劃分為實體和值對象兩種，實體模型是指業(yè)務領域中具有獨立屬性的對象；而值對象則可能是一種Description或狀態(tài)或規(guī)則。只要有實體對象，就可能存在實體的狀態(tài)，狀態(tài)跟蹤有時成為一個業(yè)務領域使用計算機軟件的首要跟蹤，但是，數(shù)據(jù)庫不是對象狀態(tài)的表達方式，只是一種存儲方式(見狀態(tài)對象：數(shù)據(jù)庫的替代者)。
圖中，實體核心對象大部分可能有一種類型，例如核心模型是產(chǎn)品，那么存在產(chǎn)品目錄；核心模型是消息；就存在消息類型；核心模型是信息；總存在信息類別，我們總是使用分類方式來管理業(yè)務領域的信息，有時，類別甚至復雜到樹形結構。
核心實體模型有時會有一個1:N關聯(lián)的子實體，一般可能表達實體的細節(jié)，例如：核心模型是訂單，那么存在訂單條目這樣一個細節(jié)，一個訂單中可能有多個訂單條目；如果核心模型是信息，那么存在該信息的多個回復或評論；這樣的關聯(lián)一般存在多個業(yè)務領域中。
相反，在實踐中，我們技術人員在經(jīng)過冗長的平臺架構學習和實踐后，就匆忙開始項目開發(fā)，這時是什么指導他們進行軟件業(yè)務實現(xiàn)呢？大部分可能是依賴數(shù)據(jù)庫建模，甚至是復雜冗長的數(shù)據(jù)庫存儲過程設計，這些已經(jīng)開始走向面向對象分析設計的反方向，走上了一條錯誤的軟件開發(fā)方向，最終開發(fā)出緩慢的、經(jīng)常當機的Java企業(yè)系統(tǒng)。
如果你沒有恰當?shù)腛O設計思想，Java就會用性能懲罰你，這可能是Java世界的一個潛規(guī)則。
那么，一個正確的OOA/OOD/OOP步驟是什么呢？目前圍繞模型驅動設計(MDD)的設計思想成為主流思想，MDA更是在MDD基礎上提升和升華。下面讓我們首先了解，如何使用領域驅動設計思想來分析設計一個軟件系統(tǒng)。
當我們不再對一個新系統(tǒng)進行數(shù)據(jù)庫提煉時，取而代之的時面向對象的模型提煉。我們必須大刀闊斧地對業(yè)務領域進行細分，將一個復雜的業(yè)務領域劃分為多個小的子領域，同時還必須分清重點和次要部分，抓住核心領域概念，實現(xiàn)重點突破。
核心領域模型
精簡模型，找出核心領域，將業(yè)務需求中最有價值的概念體現(xiàn)出來，讓核心變精要，這實際就是一個使復雜問題變簡單的過程，也是對我們軟件設計人員真正能力的考驗。
核心領域模型不是輕易能夠發(fā)現(xiàn)，特別是他處于一個紛亂復雜的眾多領域模型結構中時，核心模型通常是我們某個子領域關注的重點，例如訂單模型是訂單管理領域的核心；消息模型是論壇或消息領域系統(tǒng)的核心。
目前，分析領域有很多模式來幫助我們來提煉核心模型，例如四色原型、Martin Fowler 的分析模式等，例如MF的"分析模式"(Analysis Patterns)中的記帳模型就是不僅僅用來記錄賬目數(shù)值，而且可以記錄和控制賬目的每一次修改。而四色原型則是一種高于分析模式的一種原型基本模式，下面是本人根據(jù)四色原型提煉的核心領域模型概念。
一般情況下，在企業(yè)應用中，核心模型總是在其周圍圍繞一些所謂的“衛(wèi)星”，這實際上也是來自四色原型的一個推論
根據(jù)Eric Evans在其“領域驅動設計”一書中定義，領域模型劃分為實體和值對象兩種，實體模型是指業(yè)務領域中具有獨立屬性的對象；而值對象則可能是一種Description或狀態(tài)或規(guī)則。只要有實體對象，就可能存在實體的狀態(tài)，狀態(tài)跟蹤有時成為一個業(yè)務領域使用計算機軟件的首要跟蹤，但是，數(shù)據(jù)庫不是對象狀態(tài)的表達方式，只是一種存儲方式(見狀態(tài)對象：數(shù)據(jù)庫的替代者)。
圖中，實體核心對象大部分可能有一種類型，例如核心模型是產(chǎn)品，那么存在產(chǎn)品目錄；核心模型是消息；就存在消息類型；核心模型是信息；總存在信息類別，我們總是使用分類方式來管理業(yè)務領域的信息，有時，類別甚至復雜到樹形結構。
核心實體模型有時會有一個1:N關聯(lián)的子實體，一般可能表達實體的細節(jié)，例如：核心模型是訂單，那么存在訂單條目這樣一個細節(jié)，一個訂單中可能有多個訂單條目；如果核心模型是信息，那么存在該信息的多個回復或評論；這樣的關聯(lián)一般存在多個業(yè)務領域中。