相反，在實踐中，我們技術人員在經過冗長的平臺架構學習和實踐後，就匆忙開始項目開發，這時是什麼指導他們進行軟件業務實現呢？大部分可能是依賴數據庫建模，甚至是複雜冗長的數據庫存儲過程設計，這些已經開始走向面向對象分析設計的反方向，走上了一條錯誤的軟件開發方向，最終開發出緩慢的、經常當機的Java企業系統。
如果你沒有恰當的OO設計思想，Java就會用性能懲罰你，這可能是Java世界的一個潛規則。
那麼，一個正確的OOA/OOD/OOP步驟是什麼呢？目前圍繞模型驅動設計(MDD)的設計思想成爲主流思想，MDA更是在MDD基礎上提升和昇華。下面讓我們首先了解，如何使用領域驅動設計思想來分析設計一個軟件系統。
當我們不再對一個新系統進行數據庫提煉時，取而代之的時面向對象的模型提煉。我們必須大刀闊斧地對業務領域進行細分，將一個複雜的業務領域劃分爲多個小的子領域，同時還必須分清重點和次要部分，抓住核心領域概念，實現重點突破。
核心領域模型
精簡模型，找出核心領域，將業務需求中最有價值的概念體現出來，讓核心變精要，這實際就是一個使複雜問題變簡單的過程，也是對我們軟件設計人員真正能力的考驗。
核心領域模型不是輕易能夠發現，特別是他處於一個紛亂複雜的衆多領域模型結構中時，核心模型通常是我們某個子領域關注的重點，例如訂單模型是訂單管理領域的核心；消息模型是論壇或消息領域系統的核心。
目前，分析領域有很多模式來幫助我們來提煉核心模型，例如四色原型、Martin Fowler 的分析模式等，例如MF的"分析模式"(Analysis Patterns)中的記帳模型就是不僅僅用來記錄賬目數值，而且可以記錄和控制賬目的每一次修改。而四色原型則是一種高於分析模式的一種原型基本模式，下面是本人根據四色原型提煉的核心領域模型概念。
一般情況下，在企業應用中，核心模型總是在其周圍圍繞一些所謂的“衛星”，這實際上也是來自四色原型的一個推論，核心模型和其“衛星”的類圖如下：
根據Eric Evans在其“領域驅動設計”一書中定義，領域模型劃分爲實體和值對象兩種，實體模型是指業務領域中具有獨立屬性的對象；而值對象則可能是一種Description或狀態或規則。只要有實體對象，就可能存在實體的狀態，狀態跟蹤有時成爲一個業務領域使用計算機軟件的首要跟蹤，但是，數據庫不是對象狀態的唯一表達方式，只是一種存儲方式(見狀態對象：數據庫的替代者)。
圖中，實體核心對象大部分可能有一種類型，例如核心模型是產品，那麼存在產品目錄；核心模型是消息；就存在消息類型；核心模型是信息；總存在信息類別，我們總是使用分類方式來管理業務領域的信息，有時，類別甚至複雜到樹形結構。
核心實體模型有時會有一個1: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）。
核心模型的選擇
實際項目中，會存在多個核心模型的重疊和覆蓋使用，主要取決於你的領域關注重點。
例如當客戶和我們說要做一個旅遊網站時，我們必須充分了解需求，它的軟件系統重點是哪些功能。如果當他首先說：我需要一個酒店設備的查詢系統，因爲他的客戶對酒店設備非常關注，那麼我們可能認爲酒店設備是這個領域模型的核心；酒店設備。如果他又進行描述：我需要一個界面，客戶在輸入酒店資料時，選擇多個酒店設備，那麼在這樣一個關注領域，核心模型實際是酒店，而酒店設備可能成爲酒店的一個特徵實體屬性，甚至是值對象了。
以進銷存系統爲例子，在採購系統中，採購單是一個核心實體模型，而原材料是一種輔助實體模型；在庫存系統中，入出庫單是一個核心實體模型，原材料或成品代表的是一個庫存物品概念模型，當需要庫存報表查詢輸出，可以立即計算出來，或將結果緩存起來，緩存起來的結果其實是庫存物品對象的狀態，可以使用值對象來實現。
核心模型的精練
當核心模型被定位和確定後，相當於我們抓住領域本質，這時我們可以使用面向對象的概念對模型進行精練細化，實際就是明確對象的屬性，確定模型對象的邊界，通過反覆重構，結合GoF等設計模式，使得我們得模型準確反映本質，從而實現模型的靈活性設計。所有這些，都是數據表驅動設計所不能實現的。那你還抱着數據庫建模幹什麼呢？