DDD 模型 贫血 求指点

10-08-30 AboutUs
我被整糊涂了,请看一下我的糊涂思路

1,有一用户模型,对用户进行管理的基本操作增删改查。

2,根据我理解的DDD思想,以及避免模型贫血,新增、修改、删除的操作应当放到模型层中,

而查询、查询列表的操作应当放在服务类中,修改后类图如下

3,这样,在表现层调用时,如果是【查询列表】、【新增保存】操作,流程应当是这样:

4,就是说,有时候这个服务层需要,有时候这个服务层又不需要,这样岂非很麻烦,繁琐。如下图

5,如果是我理解的贫血模式,如下图,是不是又更简单明了

6,应当是我的理解不到位,总觉得DDD什么的,越弄越复杂了,请各位大师指点。

如果这样一个需求:对用户进行基本管理;查询用户发贴数量。要怎样设计实现。

    

oojdon
2010-08-31 03:34
2010年08月30日 23:41 "AboutUs"的内容
对用户进行基本管理;查询用户发贴数量。要怎样设计实现 ...

DDD,一种对复杂软件行为的分析方法或者思维哲学。

增删改,Report Query都不是DDD的核心也不是能够体现DDD好处的地方。

用户作为一个生命对象,以他为责任主体,如果新增,修改,删除,这些用一个事件扔给技术类去处理,比如怎么持久,怎么刷缓存等,CUD都不是用户的业务行为。

所以我觉得如增删改之类的东西放到Domain Model还是在Service都不再重要了。

AboutUs
2010-08-31 09:46
但是我记得,论坛里有帖子都争论过,getModel这个方法是不是应该放在领域模型里,还是放在Service里

如果说到重要不重要的话,当然,直接把所有操作都放到service里一样的可以实现代码,程序,系统。

但怎样更好呢

我总觉得像第4点里提到的,那种样子,很怪异。

banq
2010-08-31 15:02
2010年08月30日 23:41 "AboutUs"的内容
有时候这个服务层需要,有时候这个服务层又不需要,这样岂非很麻烦,繁琐 ...

服务是否需要,取决于你的业务场景是否复杂,以实际例子打比喻,如果你是汽车加油,需要一个加油场景,比如专门的加油站,加油站提供加油服务;如果你是给自己加水,恐怕不需要专门的场地和场景吧。

CRUD是比较简单,没有业务复杂场景的,所以,就CRUD来讨论服务,贫血模型,都是多余。

具体案例可参考JiveJdon源码吧,其帖子新增回复有业务场景,就使用了服务,而一些其他动作,就没有使用服务,而是直接界面出发领域模型。

AboutUs
2010-08-31 15:20
2010年08月31日 15:02 "banq"的内容
,其帖子新增回复有业务场景,就使用了服务,而一些其他动作,就没有使用服务,而是直接界面出发领域模型。 ...

谢谢 oojdon 及 banq大哥

猜你喜欢
2Go 1 2 下一页