领域模型中的各种角色

关于角色定义引用自《领域驱动设计》一书

[b][size=large]实体[/size][/b]---有唯一标识的对象
这个也就是我们经常定义在需要存储到数据库的那些对象，有个ID属性的，比如User,Topic等等之类的对象。


[b][size=large]值对象[/size][/b]---没有唯一标识的对象
一般是被实体在使用的另一组对象，他们没有所谓的ID属性，只有需要的符合业务要求的属性，比如Money这样的对象，你不会需要在数据库里有个专门的表来存储。因为值对象一旦创建就不能改变，每次改变都只会产生一个新的值对象，类似String。


[b][size=large]工厂[/size][/b]---定义创建实体的方法
一般来讲，也就是说当初始化代码比较长的时候，就用工厂来构建实例了。如果构造中没有任何代码，那用new完全是可以的。不要过度的去考虑这方面的设计。等需要的时候再采用这个方式。


[b][size=large]仓库[/size][/b]---管理实体的集合，并封装持久层框架
这个就很简单了。DAO。叫什么名字都无所谓吧。主要是确定范围。这个，就是用来封装持久化框架访问数据库的。当然。这里面你写JDBC和SQL也可以。


[b][size=large]服务[/size][/b]---实现无法指派给单个类的责任，并封装领域模型
这里我就要说一下了。大多数的JAVA程序设计在Service这一层没有把握好。
比如用Service中委托DAO，仅仅是出现了这样的代码：

public void save(User user){
    this.userDao.save(user);
}

这样的设计实在是难看。
Service中主要是执行了多个操作，需要有一个事务来保证完整性。
结果就是大部分的时候就是一个保存或者是更新操作，就那么一步，也加到Service里。实在让人费解。
特别是一些CRUD的系统，完全没必要有Service的存在。要了干嘛。多了一堆代码就是为了delegate，代码越多，维护越麻烦。务必要清楚这个道理才是。
只有在真正需要的时候才创建Service，这应该才是真正的设计之道。
现在我们经常说，不要为了设计模式而设计模式，不要过度设计。但这就属于最好的反面教材了。
再说一个。大多数情况下没人会在项目中途把Hibernate换掉吧。那我们要DAO接口干嘛？
接口的定义是什么？你真的是预见了未来的情况吗？

不过暂时我还没想好正式的JAVA解决办法。
不过已经稍微有点眉目了。

也许我今天写的也有不对。不过我想尽可能证明是对的，也没准，我刚好证明了我的想法又是错的。这个世界就是如此的纠结。。。

完了。。扯了一堆。。。继续发神经。