过去，当我们面对一个新的业务需求时，我们总是从先建立数据表结构开始，这种面向数据表的分析设计方法已经逐步被面向模型的分析设计方法替代。
使用数据表分析需求，无法涵括项目的全部需求设计，例如系统的状态无法统一设计，最终导致每个程序员都可以直接操控系统的状态，导致整个系统状态运行混乱；使用数据表分析，还非常容易将实体表和关系混合在一起，造成分析者视觉混乱，无法正确分析出系统的真正基本实体；使用数据表分析还会导致软件系统以数据库为中心的编码架构，进而产生传统过程化编程风格，难于维护和拓展，甚至性能低下，将系统负载都集中在数据库服务器端，走上传统的大型机集中式计算模式，而不是分布式计算模式；使用数据表分析还会丧失多层结构引以为豪的中间层，回复到过去的两层结构，更谈不上设计模式应用了。
领域建模提倡的面向模型的分析设计方法，系统一开始我们就首先确立领域模型Domain Model，以及它们之间的关系，进而可以交由程序员分别实现表现层、业务服务层和持久层，通过使用Jdon Framework（以下简称JF）等模型驱动框架，结合FDD等模型驱动的工程方法，从而正确无误地、且快速高质量地完成一个软件开发过程。
下面我们从分析、设计和开发几个环节说明一下时下流行的最新软件开发模式：
MDA步骤
Models 建模
Abstraction 抽象细化。落实细节。
Platform 平台架构选择，J2EE还是.NET，J2EE中选择如何架构，下面案例我们是选择Struts+JdonFramework+Hibernate架构平台，所以，目前JF属于整个模型驱动开发环节中Platform部分。
Model transformation 模型传递，将模型设计传递为java的类代码。
The MDA value proposition
DSM(Domain-Specific Modeling)是在上述MDA基础上，加强平台定义映射和模型映射灵活性和自住性，不象MDA工具，一出厂这个工具就确定死了平台和技术细节。
MDA工具和DSM将模型驱动软件开发过程自动化，但是实际中，更多人工手工介入，下面展示这个过程。
论坛系统的模型驱动开发
首先，我们使用UML用例图来完整清晰地表达一下一个新系统的需求，从而才能够保证正确地建模。
比如一个论坛的简单需求如下：
从这个需求中，我们需要发现那些有一定内容的实体对象，Actor1表示用户角色，用例图可以说用来表示“什么人做什么事情”，我们只要把“事情”抽象出来，作为实体对象，可能就是我们的领域模型（Domain Model），上图中发言用例实际可理解为用户发表言论，按照“什么人做什么事情”分析方法，实际是“用户”（什么人） ＋ “发表”（做） ＋ “言论”（事情），我们可以总结这里的“事情“是”言论“，”言论“作为实体对象，也就是Message（消息 帖子）。
"发言"实际就是模型Message的创建，有创建必有修改，增删改查CRUD功能必会有。
“回复”实际也是Message对象的创建，只不过有父子关系罢了。使用同样的方法可以从“浏览论坛”中分析出 Forum（论坛）这个领域对象。
Forum和Message之间类关系应该是1:N的关联，我们使用如下类图表达我们的模型：
Forum和Message提取过程是建模Modeling过程，有了模型类图；通过Abstraction细化过程，有了模型初始化以及细化。
通过Model transformation 过程，有了的模型类的java代码：
package sample.forum.model
public class Forum{
private String forumId;
private String name;
private Collection messages; //表示和Message的1:N关系（one-to-many）
.....
}
package sample.forum.model
public class Message{
private String messageId;
private String name;
private Forum forum; //表示和Forum的N:1关系（many-to-one）
.....
}
有了这两个模型类，围绕模型的业务服务接口也便诞生，如围绕Forum的ForumService和围绕Message的MessageService：
package sample.forum.service
public interface ForumService{
void createForum(EventModel em);
void updateForum(EventModel em);
void deleteForum(EventModel em);
Forum getForum(String forumId);
.....
}
自此，我们有了领域模型类和业务服务类，使用过JF的人就会发现，Jdon框架也正是需要这两种类的确立，下面就可以使用JF快速完成Forum和Message的增删改查以及批量查询两个基本功能了，见Step By Step 开发JdonFramework应用主要步骤。
仓库系统的模型驱动开发
下面再以ERP中仓库管理系统开发为例简要说明模型驱动开发过程，仓库简单用例如下：
我们再以“什么人做什么事情”来分析仓库的用例功能，“成品入库”如何分解为“什么人做什么事情”？我们可以这样理解：仓库员（什么人）+ 录入(做) + 库单（什么事情），这样，我们提炼出实体对象“库单”；进而从“商品资料维护”功能可以提炼出“商品”模型。
“成品入库”实际是“库单”的新增，必然有“库单”的增删改查CRUD功能需求。
我们建立两个模型的类图如下：
有了类图，通过模型细化和落实，我们可以有Product等三个模型代码类，进而围绕这三个模型的业务Service接口也会产生，通过使用JF的CRUD和批量查询，我们可以快速完成仓库系统的基本功能。见Step By Step 开发JdonFramework应用主要步骤。
总结
以上通过两个简单案例说明领域模型的简单提炼过程，当然实际项目中，远没有如此简单，而且也不只是模型的CRUD功能，但是我们可以通过四色图分析方法来抓住复杂系统中的模型和业务服务功能，一般四色图的MI是使用业务服务Service实现；Description是一个域模型。
JiveJdon3.0是按照模型驱动架构思路开发的一个复杂软件系统。
如图所示：模型和业务服务是在一个系统架构之前建立的，所以没有面向模型的领域建模分析方法，就没有Domain Model，就没有模型对象，就没有中间业务层，没有中间层，就没有设计模式的使用空间。同时，没有模型对象，就没有表现层的边界对象（如Struts的ActionForm）;也就没有模型对象的持久化（使用Hibernate等O/R Mapping工具），特别是在持久层使用Hibernate，最后搞个值对象VO作为数据表数据的存贮对象，很明显，对象屈从于数据表了，又在搞面向数据表的分析设计了，你这是在将汽车当自行车推了，这种对象屈从于数据表会造成如下图左边的乱糟糟结构，而右图则是因为强调了模型的统帅和领导地位，整个系统变得井井有条：
