J道解惑

07-02-15 zhaow8810
1:在现在常用的service \ dao 包结构中.子系统如果划分为类似的包XX.service.a XX.service.b XX.service.C 为三个子系统的service部分是接口 用把接口都分别放在各自的子系统包结构下吗?如果子系统中还分模块就会有XX.service.a.X

XX.service.a.Y

是不是应该把接口都放在子系统一个包中,就不用各自放在自己的模块中?因为接口只起到对下层实现隐藏细节的作用。

2:四色图中MI粉色部分与粉色部分的聚合是否代表service的注入那?比如一个MI与另外两MI之间是聚合关系,是否说明另外两个服务被注入到一个服务中那?

1
zhaow8810
2007-02-23 09:28
为什么没有人回答那?

banq
2007-03-06 10:11
注意Service只是一个外表的东西,不应该将业务核心放在service包下面,甚至建立子包,业务核心按照DDD来划分为领域层和服务层,大部分业务核心在Domain Model包下面,service只是供外界调用的简单几个接口和实现罢了。

如果你试图在service包下面深挖洞,广积粮,那么你可能没有完全理解DDD。

参看JiveJdon3的service设计。

>四色图中MI粉色部分与粉色部分的聚合

不是叫聚合,叫依赖,标识MI的依赖关系。

[该贴被banq于2007年03月06日 10:12修改过]

zhaow8810
2007-03-06 14:08
我知道你说的是model或称其为domain的那一层核心业务实体。我现在也在用只不过用其存储数据没有相应的逻辑。具体的业务逻辑都写在service层的实现里面了。现在我只是不知道划分包结构意义是否正确,现在的做法什么3个子系统每个都有一套结构比如model.A Action.A Service.A Dao.A 这是A子系统,其下还有Service.A.a (子模块)不知道您有什么建议。

zhaow8810
2007-03-06 15:20
jdon3我有看过 你也是service为接口 其下有四个service的实现包分别是imp imp.account imp.message imp.upload 这就是我所说的子模块。实现类中不就是业务逻辑吗 比如找到论坛消息 而这里面也依赖了model中的论坛消息。这我都可以理解。我要说的是你这只是一个系统。论坛系统。如果我是一个很大的系统包括几个子系统就如你那jdon3是否service可分为三个子系统的包结构 如 service.fourm

service.wiki service.blogs 类似以上这三个

banq
2007-03-07 09:57
>如果我是一个很大的系统包括几个子系统就如你那jdon3是否service可分为三个子>系统的包结构 如 service.fourmservice.wiki service.blogs 类似以上这三个

如果是一个很大的系统,从归类原则包是应该分为service.fourmservice.wiki service.blogs这几个子包,但是事情不能只从Service出发,按照DDD,Domain Model是核心,起基本决定作用,因此service是围绕Domain Model的,我的经验是:通常一个实体Model对应一个service,service分类是取决于Model的,否则,不能围绕Domain Model分类,Service就难于管理和维护。

可以想像将Service看成Model的一个行为接口,以前MF曾经指责这种Model为贫血模型或者失血模型,现在有了Evans DDD,我们可以完整的理解胖模型的概念了,而且DDD对SOA的实现提供了理论分析支持,这些都是绕口舌的东西,可以不管它,但是必须注意的就是:service只是一个行为性质接口,不要将其做复杂,否则过去误用无态EJB那样导致过程化编程,业务核心是应该在Domain Model,而不是在service,知易行难,所以也是我不主张在service深挖洞的原因。

个人意见,欢迎探讨。

猜你喜欢