根据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）。新闻热点
疑难解答
