再论 Java 应用中的“领域建模”
转载请保留作者信息:
作者:88250
Blog:http:/blog.csdn.net/DL88250
MSN & Gmail &
QQ:DL88250@gmail.com
最近又重新整理了一下项目中领域模型建模的思路。记得范凯(robbin
)
在 2005
年时候总结的四种风格的“领域模型”及其一些变种相信大家的耳熟能详了。以现在的观点来看,不管其划分是否合理,是否适合任何项目,讨论都是有意义的。从
2004 年到 2008
年来领域模型的话题一直都是各个技术论坛、邮件列表必讨论的话题之一,这里我只是想就‘领域模型建模’这个问题发表一下我的观点,相信讨论还会继续下去,这才是本质——演化。这里的观点都是基于 Java 环境上的应用展开的,其他语言环境另当别论。
相关术语与概念
首先,让我们澄清一些相关术语与概念。很多时候发现大家讨论问题前都没有一个共同的基本假设作为前提,导致了问题越讨论越混乱,引入的其他问题越来越多。这里,我先对本文涉及的几个非常基本的概念做个统一的假设。
POJO 是一个简单的、常规的 Java 对象,它包含业务逻辑处理或持久化逻辑等,但不是 JavaBean、EntityBean 等,不具有任何特殊角色并且不继承/不实现任何其它 Java 框架的类或接口(java.io.Serializable 除外)。例如下面这个类就是一个 POJO,注意业务逻辑方法:
/**
* A POJO user description.
* @author 88250
* @version 1.0.0.0, Jan 15, 2009
*/
public class User implements Serializable {
/**
* user name.
*/
private String name;
/**
* Default constructor.
*/
public User() {
}
/**
* User login business logic.
*/
public void login() {
// ....
}
/**
* Gets the name of this user.
* @return the value of name
*/
public String getName() {
return name;
}
/**
* Sets the name of this user.
* @param name new value of name
*/
public void setName(String name) {
this.name = name;
}
}
从 OO 的角度看,这是一个纯粹的 Java 类,它拥有状态与行为,这也就构成了这个 User 类的职责。可惜现在 POJO 这个词简直是滥用啊,大家都认为只要描述的是一个领域实体,一个纯数据类就是 POJO 了。
根据 Martin 大叔的解释,领域模型就是统一了行为
与数据
的对象模型
。从 OO 的角度上看是没有任何难点与疑问的,但是开始对具体项目着手进行 OO 设计的时候问题就很多了,后面将阐述一些在实施领域模型建模时“公认”的问题。再来看看 Wikipedia 上关于领域模型的解释
,其中涉及到了“领域层(Domain Layer
) ”这个概念,并且说明了 DDD 中的领域模型是领域层的一个部分
。如下图:
根据 Wikipedia 上的解释,领域层与业务层
是同一个概念,这样划分的确是纯粹的 DDD。不过,这与 JavaEE 规范中的分层理念有一点冲突,与 EJB 3 编程模型有着明显的冲突。
各种风格(Style)的领域模型
这里的“风格”是按照 Martin 的观点进行阐述的。在以往的讨论
中,有四种可行的模型:
这四种模型基本是 robbin
、JavaEye
社区思考、讨论的结果。但我认为还是按照 Martin 的提出的模型进行讨论比较简洁,有两种可行的模型:
- 贫血的领域模型(Anemic Domain Model)
- 富领域模型(Rich Domain Model)
贫血的领域模型就是在领域对象中只
包含了 accessors 方法,默认的构造器,不包含任何逻辑处理。而逻辑处理放置于 xxxManager 中,使用事务脚本(Transaction Script
,PoEAA
)进行操作。
富领域模型就是 DDD 中所描述的模型,完全的 OO Concerns
。
“公认”的问题
EJB 3 & JPA
众所周知,EJB 3 + JPA 的编程模型是典型的贫血模型,也是 JavaEE 所推广的最佳实践
,唯一正统的编程模型。 在这个模型中,EJBs 扮演了业务逻辑处理的角色,在分层设计中处于服务层 / 业务层。而 JPA entities 则扮演了典型的纯稚数据类
,其行为完全由 EJBs 负责。这些也许与早先的 SSH 这样一个无状态
框架组合那么深入人心密切相关吧。目前来说,Seam 框架 / WebBeans 规范是解决客户端与服务端状态问题的较好实现与规范。另外,Seam 中的 Entity 也是可以作为 Component 而 inject / outject 的,所以 Seam 有在尝试
提供一个 DDD 的框架给开发者。
Domain Logic vs Business Logic
如果你是一个 DDD 的纯粹拥护者,不存在区分领域逻辑与业务逻辑,统称为领域逻辑。下面这个划分领域逻辑与服务逻辑是针对类 EJB 3 + JPA 纯粹用户者的。
Domain 业务逻辑(Domain Logic)与 Service 业务逻辑(Business Logic)划分的原则:
- 根据是否依赖持久化逻辑划分
领域模型只包含不依赖于持久化
的领域逻辑,而那些依赖持久化的领域逻辑应该被分离到 Service 层
- 使用 Rod Johnson 的"case by case"原则
可重用度高的,和 domain object 状态密切关联
的放在 domain 中,可重用度低的,和 domain object 状态没有密切关联的放在 Service 中
这样,貌似是解决了 Java 应用中使用“正统”方式(JavaEE 规范)实现领域驱动开发。但是,这样不觉得过于复杂和画蛇添足吗?
结论
领域模型驱动的设计(DDD)是需要开发团队在特定行业中积累
到一定的时候才能真正做到的,这涉及到了企业(客户)的核心价值实现与业务实现重用
,如果不是本着这个最终目的
,Java 下的 DDD 慎用。在建模你的 Java 项目时,一定要对项目的 Scope 做好分析,认真做好技术选型。一般来说,贫血模型(Anemic Domain Model)是最容易设计和实现的,也足够满足一般 Java Web 项目了。而领域模型(Rich Domain Model)是用在复杂 JavaEE 项目上的(例如实施 SOA 时),切勿杀鸡用牛刀 :-)
参考列表
下面的文章是精华中的精华,有兴趣、时间的朋友一定不要错过 :-)
分享到:
相关推荐
尝试用Java3D技术构造一个协同虚拟环境工作平台原型系统,重点介绍了开发中的技术问题, 讨论了场景建模、消息通信、人机交互、化身控制、白板管理和视频显示等主要功能,并给出了一些具有较高参考价值的代码。
SMART系统-系统框架设计与开发 摘 要 SMART系统是一个新型智能在线考试信息管理系统,该系统主要实现了学生在线考试与评估以及教师对学生在线考试信息的管理和维护。本文按照SMART系统的非功能性...领域建模;系统框架
在当今流行的 We b开发技术中, JSP( java server pages)以其强大的优势,成为后起之秀,在 We b开发领域独领风骚. UML(统一建模语言, unified modeling langua在e)作为面向对象建模的标准语言 , 提供了针对具体应用的...
也论该不该在项目中使用存储过程代替SQL语句 如何使数据库中的表更有弹性,更易于扩展 存储过程——天使还是魔鬼 如何获取MSSQLServer,Oracel,Access中的数据字典信息 C#中利用GetOleDbSchemaTable获取数据库内表信息...
DSOL是由荷兰代尔夫特理工大学开发的功能齐全的多形式,分布式仿真环境。...此后,已经开发了许多论文和博士学位论文,其应用领域包括交通运输,物流,供应链管理,游戏和培训,医疗保健以及许多其他领域。其他。
它的应用领域包括:物流、供应链、制造生产业、行人交通仿真、行人疏散、城市规划建筑设计、Petri网、城市发展及生态环境、经济学、业务流程、服务系统、应急管理、GIS信息、公共政策、港口机场、疾病扩散等。...
在软件开发过程中,解决技术问题使用的方法是文献法,通过查阅课本、图书馆资料和网络在线文献、网络在线案例参考等,解决在软件开发过程中的技术问题,比如数据库、建模工具的使用、环境搭建、软件测试等。...
Modeler',用户通过指定各种正则表达式、转换图、上下文无关语法、语法定向翻译来对编程语言进行建模方案等来构建编译器模型。 使用这些规范,CAT Modeler 生成解析树、非确定性有限自动机、确定性有限自动机、语法...
第十届国防领域作战应用专题讨论会-ISSN 1983-7402,2008。 221-225。 塔兰蒂(Taranti),码头; Dominium:一种在动态和地理参考环境中调节SMA的方法,硕士论文:2008。主管:Ricardo Choren Noya。 塔兰蒂...