DDD心得

这个账号发表的第一篇文章，之前的账号因为涉嫌灌水被封掉了（以前关于泛型的文章http://www.iteye.com/topic/585900）

因为最近在看DDD，所以又想起出来冒个泡。

首先我还是想先说说泛型这个概念。泛型什么意思我就不说了，不知道的人可以去百度下。

 

之前有人说这是个语法糖的概念，其实这个只能算是语法糖。纯粹属于语法范围的东西。

 

但是我觉得这是违背面向对象思想的东西，看过DDD之后我的感触是，我们的思维太不自然了，不知道是谁告诉我有一个业务层，可能是因为Transaction Script模式让人误以为可以抽一个层出来。

 

我甚至还看到这样一种所谓的分层架构：

表示层 - 业务逻辑层 - 数据存储层

 

正如Jdon上讨论的，这种架构简直让人觉得Java就是送数据到数据库，将数据库取出来显示。那么我想知道SSH这个所谓的常用架构有意义吗？

 

看看SSH都教我们做了点什么：

STRUTS 验证表单、封装表单成一个和数据库表一一对应的对象

然后将这个对象交给Spring给我们所谓的业务逻辑层

然后业务逻辑层，整个一层都用事务包裹起来，然后呢？

送给Hibernate管理的数据存储层。。。

 

好了，其实Hibernate不用了，为什么还要用Hibernate？

谁能告诉我？因为他有缓存？搞笑吧。。

 

好吧，不信，我们举个例。

 

就拿用户（User）这个对象来说吧，我们怎么写的？？

 

 

public class User{

    private String account;
    private String password;
    private String nickname;
    private String phone;
    
    //以下是setter和getter
}

 

 

不是每个人都这么干，但是我认识的很多人都这么干。

 

呵呵，可能大家听说过”贫血模型“。

 

我还找到这么一篇论坛帖子：http://www.iteye.com/topic/16728 （其实，DDD不是王道的解决方案，他们讨论的问题我也不做褒贬。我在这里只是表达以下自己的观点，也不批评谁）

 

其实仔细学过Hibernate的人也应该有知道有<component>这个配置，有实体继承的概念，但是我想用的人不多，因为大家都是将实体直接映射过去到数据库，所谓的映射只是给我们来了点点方便，不写SQL了，改写所谓面向对象的HQL了。从数据库的N-M到实体的N-M很正常不是吗？

 

为什么我要提到所谓？因为我们真正去思考过面向对象吗？

回答是没有。

 

好吧还是用户这个概念。

 

1 . 考虑这样一个场景，普通的论坛网站。我们有一个用户，这个用户哪里来的？系统内定义好的？不是，外部注册的，可能用户有很多很多信息。

 

但是现实生活中的的确确有用户，那么我们所谓的用户有哪几种？普通用户、管理员等等。

 

那么我们的对象用该长什么样？其实所谓的用户是个抽象出来的概念。

 

 

public abstract class User{
}

 

 

 那么用户需要什么属性？很难想。。对，因为我们没有结合生活。思维回归自然。

 

想想我们去银行取钱怎么干的？拿出了一张卡，对一张卡。

 

 

public class Certification{
    protected string account;
    protected string password;
    //setter;getter
}

 

谁拿的？当然是用户

 

 

public abstract class User{
     protected Certification certification;
     //setter;getter;
}

OK，这就是两个对象了

 

想想登录这个事情，谁的行为，谁做登录这个事情……

 

用户，对，用户。

 

public abstract class User {

    //刚才的代码省略掉
    
    public void login(){
       //详细代码省略
    }
}

 

OK，这里就引入了一个对象状态的概念了。用户已经正确进入系统，并激活。

 

那么用户有几种状态？

1.不在系统内

2.在仓储休息，没有被激活

3.被激活但是没有登录系统

4.登出系统时被激活了

5.放回仓储

6.从仓储中删除，移除整个系统

 

下面我们说说Value Object这个概念，详细的请参考DDD这本书。

 

当然，所谓的value object的划分是一个很微妙的概念，你可以将Certification作为Value Object也可以不，为什么？

如果这个”证书“可以被其他人继续使用，比如：手机号码系统，如果这个号码可以被别的人继续使用，那么他就不是值对象，如果她跟着用户一起销毁，他就是一个值对象。

 

也就是我们说的聚合和聚集的概念，也是我们常常说的对象生命周期的概念。

 

当然辨别这个Certification是否作为值对象还有一个标准，那就是唯一标识，其实你也知道他是有的，但是我们是否需要将这个唯一标志暴露给别人呢？或者说这个标志是不是用来拿去Certification这个对象的呢？当然。。。不是，我们是用这个值对象来拿去User的，User才是我们的重头戏，而不是Certification。

 

怎么思考？其实就从这个角度去想，银行取钱关心的是Certification，而不是User，那么他就不是值对象，而是实体，因为我们需要这个卡号，而Certification才需要关联一个User，根据卡得到人。

 

JavaEye也一样。。。我的账号已经被保留了，但是用户的某些信息已经Over了，比如说我的Email可能已经不在数据库了。

 

好吧，继续，我们讨论一个普通网站的用户系统。

这个系统最主要的是用户而不是这个卡号，这个卡号需要跟随用户一起存在，那么，如果用户丢失了，是不是应该保留用户信息呢？这是一个问题，普通网站是这么干的，不需要了，那么Certification就是值对象。

 

好了。。抛砖引玉，欢迎拿玉砸我，这些都是个人见解，也算是笔记吧，这本书我还在继续研究。