有界上下文(Bounded Context)主要是领域系统边界，精确定义问题域，避免歧义等。
领域服务：定义明确的交互行为，如：上下文内聚合根之间、上下文之间、应用层与领域层之间

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

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

另外，我希望从“命名”上不要随意违反常识，从'领域模型“的角度看，对外叫服务，对内叫功能。
[该贴被flyzb于2013-01-20 19:58修改过]

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

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

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

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

事件，缓存，存储，，，我们抛开不看了，本来就是方法论，，，与业务无关。。。

话转回场景，放在应用层还是领域层？其实我倒还喜欢放到应用的，领域，只是提供领域对象和交互。。。

仓储，可不也是领域服务其一么，服务这个概念太广了，，，那么仓储有业务含义么？

转到值对象，我看到mapper，呵呵SOA的标志，，，我们看来可以把一切都叫服务，或者把服务叫做别的，，，唯一想对lz说的，就是领域层是分析域的，与数据和应用无关，如果你要DDD，那么值对象为何到了数据层。。。你可以理解它为别的东西，如果用DDD的概念，还是别叫值对象为好，免得误会。。。banq讲得可真委婉。。。呵呵

你又发明了一个数据实体，，，更加迷离了，，，到底是数据还是实体，业务的么？傻傻分不清楚啊，，，

最后，你提及把领域放到底层，这个忍不住，不同意了，分层的目的简单说是为了分清楚外，还有一个上知下而下不知上（后来又被从技术上颠覆了），而用DDD的分层也是如此，如果你搬它，很显然不一致，banq自己在很多回复里面常常很轻视最后的数据层，也是表达一个观点，领域层的东西是自给自足的，只有2个东西，对象（你叫实体和值对象也好）和交互（你叫服务也好，场景也好），然后。。。呵呵

我的值对象也就是Address之类的POJO对象，一个Address里可以包含国家、省份、城市等信息。

我总是觉得领域层之下应该有一些基础的、公用的数据结构，当然这些数据结构和DB无关。

就好像继承一样，一个领域如果继承于另一个领域，至少编码起来会方便很多。比如说，针对金融行业、电子商务、ERP等分别构建公共领域和业务规则，因为红冲、作废、抵扣之类的业务规则是不可能变化的。

这里的值对象和DDD中的Value Object应该不是同一个东西，这里可以看作是DTO。

感觉Repo和DomainService的实现都应该在Infrastructure层.
ValueObject好像也应该是Domain Model的一种啊?

重实践理性，能够从SSH的惯性中跳出来，就很不错了。
学术纠缠以及名词辨析，误导。概念理解体现功底，不过理解再正确，实际开发软件时，没法得心应手，又何用？

值对象应该属于领域层吧？