根據Eric Evans在其“領域驅動設計”一書中定義，領域模型劃分為實體和值對象兩種，實體模型是指業務領域中具有獨立屬性的對象；而值對象則可能是一種Description或狀態或規則。只要有實體對象，就可能存在實體的狀態，狀態跟蹤有時成為一個業務領域使用計算機軟件的首要跟蹤，但是，數據庫不是對象狀態的唯一表達方式，只是一種存儲方式(見狀態對象：數據庫的替代者)?！ D中，實體核心對象大部分可能有一種類型，例如核心模型是產品，那么存在產品目錄；核心模型是消息；就存在消息類型；核心模型是信息；總存在信息類別，我們總是使用分類方式來治理業務領域的信息，有時，類別甚至復雜到樹形結構?！ 『诵膶嶓w模型有時會有一個1:N關聯的子實體，一般可能表達實體的細節，例如：核心模型是訂單，那么存在訂單條目這樣一個細節，一個訂單中可能有多個訂單條目；假如核心模型是信息，那么存在該信息的多個回復或評論；這樣的關聯一般存在多個業務領域中。模型界面實現 原來，我們以為分析設計階段無需了解實現細節，分析人員只要悶頭做分析UML圖，而無需顧及如何具體實現，其實這是一個誤區。 Eric Evans在其“領域驅動設計”一書中認為：分析人員負責從領域中收集基本概念； 設計則必須指明一組適應編程工具構造的組件，以及這些組件必須能夠在目標環境中有效執行。模型驅動設計(Model-Driven Design)拋棄了分裂分析模型與設計的做法，使用單一的模型來滿足這兩方面的要求。因此，對于核心模型必須把握了解其實現細節?！ 牧硗庖粋€方面來說，中國的客戶總是從界面設計來表達他們的意圖（假如中國客戶能夠使用Use Case等UML圖來表達他們概念真是不可想象），例如客戶會說，我希望有一個界面讓我將訂單數據輸入，然后能夠查詢符合查詢條件的訂單。因此，我們的核心模型至少能夠順利地映射到界面實現，相反，這個客戶有這樣訂單界面要求，但是你沒有提供一個與之適應的核心實體模型，界面實現將變得復雜，甚至走很多彎路，誕生不少DTO垃圾對象?！ ∫訨donFramework框架實現為例子，框架提供了圍繞核心模型的新增刪除修改查詢(CRUD)功能以及批量功能的快速實現，尤其CRUD功能實現前提是必須提煉出核心模型，從而其界面設計流程就能通過配置立即實現，這樣一步到位實現領域模型到界面的過渡，可以將我們設計核心模型和客戶要求的界面需求能夠做到完整的統一?！ ￠_源JdonFramework下載包中message案例實際就是上述核心模型圖的一種實現項目，更復雜的項目可以認為是核心模型的重疊和反復使用（從原理上講，核心模型是四色原型的體現，而四色原型被認為是大部分企業系統的基本組成元素，見[book][UML][Peter Coad]Java Modeling in Color with UML）。新聞熱點
疑難解答
