原来，我们以为分析设计阶段无需了解实现细节，分析人员只要闷头做分析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等设计模式，使得我们得模型准确反映本质，从而实现模型的灵活性设计。所有这些，都是数据表驱动设计所不能实现的。那你还抱着数据库建模干什么呢？