丁亮的个人博客   Java/Go/Linux/开源

GitHub 上 Star 数最多的 Java 博客 Solo
Golang 黑科技之在线 IDE Wide
黑客与画家的社区 Sym

再论 Java 应用中的“领域建模”

再论 Java 应用中的“领域建模”

 

转载请保留作者信息:

作者:88250

Blog:http:/blog.csdn.net/DL88250

MSN & Gmail & QQ:DL88250@gmail.com

 

 



最近又重新整理了一下项目中领域模型建模的思路。记得范凯(robbin ) 在 2005 年时候总结的四种风格的“领域模型”及其一些变种相信大家的耳熟能详了。以现在的观点来看,不管其划分是否合理,是否适合任何项目,讨论都是有意义的。从 2004 年到 2008 年来领域模型的话题一直都是各个技术论坛、邮件列表必讨论的话题之一,这里我只是想就‘领域模型建模’这个问题发表一下我的观点,相信讨论还会继续下去,这才是本质——演化。这里的观点都是基于 Java 环境上的应用展开的,其他语言环境另当别论。

相关术语与概念

首先,让我们澄清一些相关术语与概念。很多时候发现大家讨论问题前都没有一个共同的基本假设作为前提,导致了问题越讨论越混乱,引入的其他问题越来越多。这里,我先对本文涉及的几个非常基本的概念做个统一的假设。

POJO(Plain Old Java Object

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 了

领域模型(Domain Model

根据 Martin 大叔的解释,领域模型就是统一了行为 数据 对象模型 。从 OO 的角度上看是没有任何难点与疑问的,但是开始对具体项目着手进行 OO 设计的时候问题就很多了,后面将阐述一些在实施领域模型建模时“公认”的问题。再来看看 Wikipedia 上关于领域模型的解释 ,其中涉及到了“领域层(Domain Layer ) ”这个概念,并且说明了 DDD 中的领域模型是领域层的一个部分 。如下图:

 

domain

 

根据 Wikipedia 上的解释,领域层与业务层 是同一个概念,这样划分的确是纯粹的 DDD。不过,这与 JavaEE 规范中的分层理念有一点冲突,与 EJB 3 编程模型有着明显的冲突。

各种风格(Style)的领域模型 

这里的“风格”是按照 Martin 的观点进行阐述的。在以往的讨论 中,有四种可行的模型:

  • 失血模型
  • 贫血模型
  • 充血模型
  • 胀血模型


这四种模型基本是 robbinJavaEye 社区思考、讨论的结果。但我认为还是按照 Martin 的提出的模型进行讨论比较简洁,有两种可行的模型:

  • 贫血的领域模型(Anemic Domain Model)
  • 富领域模型(Rich Domain Model)

贫血的领域模型(Anemic Domain Model

贫血的领域模型就是在领域对象中 包含了 accessors 方法,默认的构造器,不包含任何逻辑处理。而逻辑处理放置于 xxxManager 中,使用事务脚本(Transaction ScriptPoEAA )进行操作。

 

富领域模型(Rich Domain Model

富领域模型就是 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)划分的原则:

  1. 根据是否依赖持久化逻辑划分
    领域模型只包含不依赖于持久化 的领域逻辑,而那些依赖持久化的领域逻辑应该被分离到 Service 层
  2. 使用 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 时),切勿杀鸡用牛刀 :-)

参考列表

下面的文章是精华中的精华,有兴趣、时间的朋友一定不要错过 :-)

 

 

---- EOF ----
欢迎加入开源技术 Q 群 13139268 B3log,让学习和分享成为一种习惯!
validate