学文网当Java世界提供的可选择性框架平台越来越多时，我们可能被平台架构所深深困扰，而无暇顾及软件的真正核心：业务建模，其实，业务领域建模同样是一个比平台架构更复杂，更需要学习的新的领域。
在实践中，我们技术人员在经过冗长的平台架构学习和实践后，就匆忙开始项目开发，这时是什么指导他们进行软件业务实现呢？大部分可能是依赖数据库建模，甚至是复杂冗长的数据库存储过程设计，这些已经开始走向面向对象分析设计的反方向，走上了一条错误的软件开发方向，最终开发出缓慢的、经常当机的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案例实际就是上述核心模型***的一种实现项目，更复杂的项目可以认为是核心模型的重叠和反复使用。
核心模型的选择
实际项目中，会存在多个核心模型的重叠和覆盖使用，主要取决于你的领域关注重点。
例如当客户和我们说要做一个旅游网站时，我们必须充分了解需求，它的软件系统重点是哪些功能。如果当他首先说:我需要一个酒店设备的查询系统，因为他的客户对酒店设备非常关注，那么我们可能认为酒店设备是这个领域模型的核心;酒店设备。如果他又进行描述:我需要一个界面，客户在输入酒店资料时，选择多个酒店设备，那么在这样一个关注领域，核心模型实际是酒店，而酒店设备可能成为酒店的一个特征实体属性，甚至是值对象了。
以进销存系统为例子，在采购系统中，采购单是一个核心实体模型，而原材料是一种辅助实体模型;在库存系统中，入出库单是一个核心实体模型，原材料或成品代表的是一个库存物品概念模型，当需要库存报表查询输出，可以立即计算出来，或将结果缓存起来，缓存起来的结果其实是库存物品对象的状态，可以使用值对象来实现。
核心模型的精练
当核心模型被定位和确定后，相当于我们抓住领域本质，这时我们可以使用面向对象的概念对模型进行精练细化，实际就是明确对象的属性，确定模型对象的边界，通过反复重构，结合GoF等设计模式，使得我们得模型准确反映本质，从而实现模型的灵活性设计。所有这些，都是数据表驱动设计所不能实现的。那你还抱着数据库建模干什么呢？
为艺术而生技术
DDD(领域驱动建模)是告诉我们如何做好业务层！并以领域驱动设计思想来选择和合适的框架，本文以基于JdonFramework开发的JiveJdon3.0说明DDD方法的实战应用。
首先必须认识到:领域建模是一种艺术的技术，不是数学的技术，它是用来解决复杂软件快速应付变化的解决之道（快速适应需求变化的软件复用）。
我们知道软件的产生过程是:分析、设计、编程、测试、部署。过去，分析领域和软件设计是***的，分析人员从领域中收集基本概念;而设计必须指明一组能北项目中适应编程工具构造的组件，这些组件必须能够在目标环境中有效执行，并能够正确解决应用程序出现的问题。模型驱动设计(Model-Driven Design)抛弃了***分析模型与设计的做法，使用单一的模型来满足这两方面的要求。这就是领域模型。
单一的领域模型同时满足分析原型和软件设计，如果一个模型实现时不实用，重新寻找新模型。如果模型没有忠实表达领域关键概念时，也必须重新寻找新的模型。 建模和设计成为单个迭代循环。将领域模型和设计紧密联系。因此，建模专家必须懂设计，会编程。象的状态，可以使用值对象来实现。
那种将业务逻辑交由业务界面处理的快速UI方式是旁门左道。希望象C/S结构那样可视化拖拖***形就完成的软件开发是一种错误的方向，开发时快速，难于维护和扩展，虽然使用J2EE技术，其实是一种伪多层技术。
链接
领域驱动的层次划分
业务层将细分为两个层次：应用层和领域层。它们的定义是:应用层:定义软件可以完成的工作，并且指挥具有丰富含义的领域对象来解决问题，保持精练;不包括业务规则或知识，无业务情况的状态;领域层:负责表示业务概念、业务状态的信息和业务规则，是业务软件核心。
层次之间必须清晰分离，每个层都是内聚的，并且只依赖它的下层，为了实现各层的最大解耦，Ioc模式和Ioc容器是目前最好的选择。