当Java世界提供的可选择性框架平台越来越多时，我们可能被平台架构所深深困扰，而无暇顾及软件的真正核心：业务建模，其实，业务领域建模同样是一个比平台架构更复杂，更需要学习的新的领域。

　　相反，在实践中，我们技术人员在经过冗长的平台架构学习和实践后，就匆忙开始项目开发，这时是什么指导他们进行软件业务实现呢？大部分可能是依赖数据库建模，甚至是复杂冗长的数据库存储过程设计，这些已经开始走向面向对象分析设计的反方向，走上了一条错误的软件开发方向，最终开发出缓慢的、经常当机的Java企业系统。

　　如果你没有恰当的OO设计思想，Java就会用性能惩罚你，这可能是Java世界的一个潜规则。

　　那么，一个正确的OOA/OOD/OOP步骤是什么呢？目前围绕模型驱动设计(MDD)的设计思想成为主流思想，MDA更是在MDD基础上提升和升华。下面让我们首先了解，如何使用领域驱动设计思想来分析设计一个软件系统。

　　当我们不再对一个新系统进行数据库提炼时，取而代之的时面向对象的模型提炼。我们必须大刀阔斧地对业务领域进行细分，将一个复杂的业务领域划分为多个小的子领域，同时还必须分清重点和次要部分，抓住核心领域概念，实现重点突破。

　　核心领域模型

　　精简模型，找出核心领域，将业务需求中最有价值的概念体现出来，让核心变精要，这实际就是一个使复杂问题变简单的过程，也是对我们软件设计人员真正能力的考验。

　　核心领域模型不是轻易能够发现，特别是他处于一个纷乱复杂的众多领域模型结构中时，核心模型通常是我们某个子领域关注的重点，例如订单模型是订单管理领域的核心；消息模型是论坛或消息领域系统的核心。

　　目前，分析领域有很多模式来帮助我们来提炼核心模型，例如四色原型、Martin Fowler 的分析模式等，例如MF的"分析模式"(Analysis Patterns)中的记帐模型就是不仅仅用来记录账目数值，而且可以记录和控制账目的每一次修改。而四色原型则是一种高于分析模式的一种原型基本模式，下面是本人根据四色原型提炼的核心领域模型概念。

　　一般情况下，在企业应用中，核心模型总是在其周围围绕一些所谓的“卫星”，这实际上也是来自四色原型的一个推论，核心模型和其“卫星”的类图如下：

  　

　　根据Eric Evans在其“领域驱动设计”一书中定义，领域模型划分为实体和值对象两种，实体模型是指业务领域中具有独立属性的对象；而值对象则可能是一种Description或状态或规则。只要有实体对象，就可能存在实体的状态，状态跟踪有时成为一个业务领域使用计算机软件的首要跟踪，但是，数据库不是对象状态的唯一表达方式，只是一种存储方式(见状态对象：数据库的替代者)。

　　图中，实体核心对象大部分可能有一种类型，例如核心模型是产品，那么存在产品目录；核心模型是消息；就存在消息类型；核心模型是信息；总存在信息类别，我们总是使用分类方式来管理业务领域的信息，有时，类别甚至复杂到树形结构。

　　核心实体模型有时会有一个1:N关联的子实体，一般可能表达实体的细节，例如：核心模型是订单，那么存在订单条目这样一个细节，一个订单中可能有多个订单条目；如果核心模型是信息，那么存在该信息的多个回复或评论；这样的关联一般存在多个业务领域中。