java和建模,java领域模型设计实例

　　最近我在项目中重新整理了领域模型建模的思路。记得范凯(罗宾

　　2005年

　　我相信你对2000年总结的“领域模型”的四种风格以及它们的一些变种很熟悉。从目前来看，无论其划分是否合理，是否适合任何项目，讨论都是有意义的。从

　　从2004年到2008年

　　近年来，领域模型的话题一直是各种技术论坛和邮件列表中必谈的话题之一。在这里，我只想表达一下我对‘领域模型建模’这个问题的看法。我相信讨论还会继续，这就是3354进化的精髓。这里所有的观点都是基于Java环境下的应用，其他语言环境另当别论。

　　相关术语和概念首先，我们来明确一些相关的术语和概念。很多时候发现，在我们讨论问题之前，没有一个共同的基本假设作为前提，导致越来越多的混乱，引入更多的其他问题。在这里，我将对本文涉及的几个非常基本的概念做一个统一的假设。

　　POJO(普通旧Java对象

　　)POJO是一个简单常规的Java对象，包含业务逻辑处理或持久化逻辑，但不是JavaBean、EntityBean等。它没有任何特殊角色，也不继承/实现任何其他spring mvc类或接口(java.io.Serializable除外)。例如，下面的类是一个POJO。注意商业逻辑方法：

　　/**

　　* POJO用户描述。

　　* @作者88250

　　* @版本1.0.0.0，2009年1月15日

　　*/

　　公共类用户实现可序列化{

　　/**

　　*用户名。

　　*/

　　私有字符串名称；

　　/**

　　*默认构造函数。

　　*/

　　公共用户(){

　　}

　　/**

　　*用户登录业务逻辑。

　　*/

　　公共void登录(){

　　//.

　　}

　　/**

　　*获取该用户的名称。

　　* @返回名称的值

　　*/

　　公共字符串getName() {

　　返回名称；

　　}

　　/**

　　*设置该用户的名称。

　　* @param name名称的新值

　　*/

　　public void setName(字符串名){

　　this.name=name

　　}

　　从OO的角度来看，这是一个纯Java类，有状态和行为，构成了这个用户类的职责。可惜现在POJO这个词简直被滥用了。大家认为只要描述了一个域实体，纯数据类就是POJO。

　　领域模型

　　按照马丁叔叔的解释，域模型就是统一行为。

　　的对象模型。从OO的角度来说，没有什么困难和疑惑，但是当我们开始为具体项目设计OO的时候，就出现了很多问题。稍后，将阐述实现领域建模中的一些“公认的”问题。我们来看看维基百科上对领域模型的解释。

　　，这涉及到“领域层(Domain Layer

　　)”，并解释了DDD的领域模型是领域层的一部分。如下图：

　　根据维基百科上的解释，领域层和业务层

　　是同一个概念，这个划分真的是纯DDD。但是这种思想和JavaEE规范中的分层思想有点冲突，和EJB 3编程模型有明显的冲突。

　　各种风格(style)的领域模型这里的“风格”是根据马丁的观点来阐述的。在以前的讨论中

　　在中，有四种可行的模型：

　　贫血模型

　　四款基本都是罗宾汉。

　　JavaEye

　　社区思考和讨论的结果。但是我觉得按照马丁的模型来讨论更简单。有两种可行的模式：

　　贫血的贫血域模型。

　　富域模型(Rich Domain Model)

　　贫血的贫血域模型

　　贫血领域模型是唯一

　　包含默认构造函数accessors方法，没有任何逻辑处理。逻辑处理放在xxxManager中，事务脚本(Transaction Script

　　，PoEAA

　　)进行操作。

　　丰富域模型

　　)

　　富域模型是DDD描述的模型，完全面向对象的关注点。

　　“公认的”问题

　　EJB 3 & JPA

　　众所周知，EJB 3 JPA的编程模型是典型的贫血模型，也是JavaEE推广的最佳实践。

　　，唯一正统的编程模型。在该模型中，EJB扮演业务逻辑处理的角色，在分层设计中处于服务层/业务层。而JPA entities扮演的是典型的纯数据类。

　　，其行为完全由EJB负责。也许这些在早期的SSH中是无状态的。

　　框架如此深入人心，息息相关。目前Seam Framework/WebBeans规范是解决客户端和服务器端状态问题的很好的实现和规范。另外，Seam中的实体也可以作为组件注入/弹出，所以Seam正在尝试。

　　为开发者提供一个DDD框架。

　　领域逻辑与业务逻辑

　　如果你是DDD的纯粹支持者，领域逻辑和业务逻辑是没有区别的，统称为领域逻辑。下面的域逻辑和服务逻辑是针对EJB 3 JPA的纯用户的。

　　领域逻辑和服务业务逻辑的划分原则：

　　根据是否依赖持久逻辑。

　　该模型仅包含与持久性无关的。

　　领域逻辑和那些依赖于持久性的逻辑应该被分离到服务层中。

　　使用罗德约翰逊的“个案处理”原则。

　　它与领域对象的状态密切相关，具有很高的可重用性。

　　在领域中，重用性低的和与领域对象状态不密切相关的被置于服务中。

　　这样看来，似乎解决了Java应用中使用“正统”方式(JavaEE规范)实现域驱动开发的问题。但是你不觉得太复杂了，画蛇添足吗？

　　结论

　　领域驱动设计(DDD)需要开发团队在特定行业的积累。

　　要等到一定时间才能做到，这涉及到企业(客户)的核心价值实现和业务实现复用。

　　如果不是为了这个最终目的

　　，Java下的DDD要慎用。在为您的Java项目建模时，一定要分析项目的范围，并仔细选择技术。一般来说，贫血域模型是最容易设计和实现的，它足以满足一般的Java Web项目。并且在复杂的JavaEE项目中使用富域模型(例如，在实现SOA时)。不要用刀杀鸡：-)

　　引用表

　　下面这篇文章是精华中的精华。有兴趣有时间的朋友一定不要错过：-)

　　贫血域模型

　　总结最近关于领域对象及相关问题的讨论。

　　一个简单的例子：贫血模型或领域模型

　　领域模型实现综述

　　领域模型的价值与困境

郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。