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） 
　　.....
} 

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作为数据表数据的存贮对象，很明显，对象屈从于数据表了，又在搞面向数据表的分析设计了，你这是在将汽车当自行车推了，这种对象屈从于数据表会造成如下图左边的乱糟糟结构，而右图则是因为强调了模型的统帅和领导地位，整个系统变得井井有条。