UML sequence图中类的责任设计的疑问

07-08-17 miaoxikui
         

在当前可以说UML已经很使用了,但是最近在做投票系统模型设计的时候,有点疑问。按照DDD设计模型是:Vote(voteId , voteTitle,totalNum)和

VoteItem(voteItemId,voteItemName,voteNum,voteId)

使用Struts+Hibernate做:疑问:

就是在设计VoteItem类(vo类)的时候,我觉得该类应该有投票数量增加的责任,所以应该把该方法作为该类的成员(我觉得)。

public void increaseVotenum()

{

int num = getVotenum().intValue() + 1;

setVotenum( Integer.valueOf( num ) );

}

问题出来了,模型类中出现了业务逻辑,而我的service包中的ServiceFactory类来得到service的单一实例。serviceImpl包中是服务的实现类。然后在服务实现类中写具体的业务逻辑,这应该才是正常的。所以increaseVotenum()方法应该写在服务实现类中。

另外我还有一个附带的疑问是:

在我的服务实现类中仍然使用了DAO设计模式,为了达到真正的解耦还定义了DAO接口和DAO的实现类(在这里我且不详细说DAO实现类的功能)DAO实现类的总体功能就是对数据库进行CRUD的基本操作和一些其他的我认为与数据库相关的功能(分页的方法),我有觉得这些方法也应该算在业务逻辑中吧!就是说我想把DAO中的内容转移到service(业务逻辑中来实现)中引入DAO是多余的吗 ?

我想问的是在JAVA WEB软件架构中DAO 与service同时存在是合理的吗》?

         

banq
2007-08-20 10:32

>然后在服务实现类中写具体的业务逻辑

依据Evans DDD,是不应该在服务中写业务逻辑,而应该在领域层,领域层不一定是模型类,就你这个案例:首先increaseVotenum方法应该在VoteItem还是在相应的服务类中的问题,我觉得放在VoteItem中好,这样模型也比较丰富,如果increaseVotenum方法很重要,也可以将increaseVotenum方法放入一个VoteItem代理类中。

>想把DAO中的内容转移到service(业务逻辑中来实现)

Evans DDD中将DAO归为对象的工厂或者仓库,也就是说:数据库只是对象的仓库,其他就什么都不是。

因此:DAO不应该有业务逻辑,只是复杂对象的持久化,就象我们经常使用save功能一样ctrl-s。如果你将业务逻辑使用复杂SQL实现,就使DAO包含逻辑,你所要做的就是简化SQL,使业务从SQL中分离出来,一般人没有这样功力,因此,必须老老实实从对象分析设计重新开始。

建议你们学习或培训一下Evans DDD,可以解决你很多这样的疑惑。

miaoxikui
2007-08-22 08:52

引用 “领域驱动设计强调有一个专门的领域层,领域层不只是模型,还包括与模型相关的用来完成业务逻辑的其他元素,如服务等”。

领域层=模型驱动设计中单纯的模型+维护这些模型的完整性操作+模型之间的关联维护+提供模型访问的方法

---》依据Evans DDD,是不应该在服务中写业务逻辑,而应该在领域层,领域层不一定是模型类

我的理解:“不应该在服务中写业务逻辑,而是应该在领域层”是因为领域层“还包括与模型相关的用来完成业务逻辑的其他元素,如服务等”那么在DDD中是不是就不会存在业务逻辑层了呢?就我了解的软件开发模型为 表示层(UI) 业务逻辑层 持久层

数据层(模型)在DDD中业务逻辑层将不会存在!相应地DDD代替了业务逻辑层 持久层和数据层(模型)。我理解的对吗?

banq
2007-08-22 09:14

一般分层是表现层 业务逻辑层 和持久层。不会存在数据层,之所以有数据层概念是因为围绕数据库设计编程观点导致。

领域层实际就是业务逻辑层的细化,业务逻辑层细化为应用层和领域层两个。

服务也是分层的,分为应用层服务和领域层服务。

总之,业务逻辑尽量使用模型和相关类来表达。

miaoxikui
2007-08-22 10:38

谢谢banq大师的指导

最近想学习DDD ,我应该学习DDD的思想了。banq能否推荐几本经典的书籍呀

2Go 1 2 下一页