clonalman
2013-01-20 12:07

有界上下文(Bounded Context)主要是领域系统边界,精确定义问题域,避免歧义等。

领域服务:定义明确的交互行为,如:上下文内聚合根之间、上下文之间、应用层与领域层之间

flyzb
2013-01-20 19:38

2013-01-20 09:53 "@gameboyLV"的内容
OrderNumberService还能为应用层做事 ...

呵呵。。咱们咬文嚼字一下。“服务”就是提供一种业务功能,而“领域服务”就是领域模型为上层提供业务功能的接口,说白了就是领域模型的逻辑外观层。领域服务是领域模型为应用层提供某种的业务功能的接口,当然属于领域层。

“上下文”是指领域模型的边界,而这种边界是由领域模型的所有领域服务共同构建出的一种“服务契约”。

另外,我希望从“命名”上不要随意违反常识,从'领域模型“的角度看,对外叫服务,对内叫功能。

[该贴被flyzb于2013-01-20 19:58修改过]

banq
2013-01-21 08:32

2013-01-20 19:38 "@flyzb"的内容
我希望从“命名”上不要随意违反常识 ...

这个我也是同意的,其实这种问题的发生我认为也是体现DDD的一个弱点之处,领域模型分 实体 值对象和服务三种,实体和值对象表达名词概念,动词概念本来可以用普通函数来表达,但是按照二选一,只能选择‘服务’来表达,而‘服务’的通俗概念不是一般意义上的函数接口,容易引起混淆。

如果在这里引入“事件”概念可能就很清晰了,实体 值对象 、服务 和事件,四个要素,这样在领域层,为实体服务的函数就不叫领域服务,而称为领域事件,实体通过发出各种事件调度技术架构为其服务,而将领域服务真正落实为开放给应用层的接口。

[该贴被banq于2013-01-21 08:34修改过]

root
2013-01-22 14:41

2013-01-21 08:32 "@banq"的内容
如果在这里引入“事件”概念可能就很清晰了,实体 值对象 、服务 和事件,四个要素,这样在领域层,为实体服务的函数就不叫领域服务,而称为领域事件,实体通过发出各种事件调度技术架构为其服务,而将领域服务真正落实为开放给应用层的接口。

...

如果这么交流的话,从领域边界提供的事件接口来看,楼主提供的仓储模型是不是只提供了仓储事件接口?事件是不是应该有更多的逻辑性以体现领域服务?

abbasky
2013-02-08 06:01

看了楼主的DDD应用,非常认同楼主的做法,但是我有些疑问,在楼主的仓储做了些什么工作呢?能否指点一二,谢谢!

6Go 上一页 1 2 3 4 5 6 下一页