关于应用层和领域层逻辑的区分？

老师我不敢称，来说说我的看法吧，我觉得那个service应该是应用层的服务！

两者混合在一起了，没有进行严格区分，以Jivejdon3这样中小型系统，个人认为过细分层也带来复杂性

哦，多谢。我觉得应用层服务和领域层服务很难分清楚，有时候感觉即可以是应用层服务也可以是领域层服务，请问有什么判断的依据来区分应用层服务和领域层服务吗？

>请问有什么判断的依据来区分应用层服务和领域层服务吗
就是看是否是和业务相关，比如一个EMail发送服务，属于通用的技术架构，涉及具体的软件技术，和业务没有关系，那么它就是应用层服务。这个分辨需要很强敏感性，挺费脑筋。其实敏感体质就不好，容易感冒等，虽然聪明，但容易受伤。哈哈。

好像是楚留香说的。

想不到banq也这么幽默！

>比如一个EMail发送服务，属于通用的技术架构，涉及具体的软件技术，和业务没有关系，那么它就是应用层服务

应用层好像只起一个协调的作用哟！书上说：应用层负责的任务不包括处理业务规则或知识，只是给下一层中相互协作的领域对象协调任务、委托工作。在这个层次中不反映业务情况的状态，但反映用户或程序的任务进度的状态。因此我认为它应该不会涉及到具体的软件技术哟！它应该只起一个辅助领域层的作用吧！

而领域层才具体的反映业务状态的变化，当然实现细节也不由它来完成，由基础结构层来完成.
[该贴被Hqiu于2008-12-05 00:32修改过]

Hqiu
尽信书不如无书，跑题了~~~，你读书读偏了。

“层”可大可小，要看怎么划分了。在一个整体的业务中mail只是一个子功能模块，封闭的完成了一个中间任务“传送mail”，从这个角度上说他是一个应用层服务

发送email 应该属于 基础设施层吧，不应该属于应用层

其实我是这样理解的：
发送EMAIL——主动方“用户”，被东方“EMAIL”，操作“发送”。

1、EMAIL是需要跟踪的（类似谁发的，删除的，草稿的，发送的，接收的，已读的等），是一个实体；我们用户发送EMAIL，实际上有业务逻辑，这个逻辑是备份EMAIL，如发送时复制一份作记录。（注意，并不是保存到数据库）

2、保存到仓储和数据库是基础设施层的范畴，与发送这个操作没任何关系；但发送EMAIL，需要EMAIL的相关技术支持，如EMAIL协议，规则等东东，所以也包含对设施的一点引用。

3、发送是一个用户操作，肯定经过应用层，单单“发送”这一动作可以看作是领域与外界的一个交互，也就是不应该属于领域的，也就是不属于领域服务，而是应用层服务，但往往在实际开发中，我们需要加入记录发过邮件的跟踪业务，所以，在实际上说的话，也包含领域服务部分。

总的来说，EMAIL主要属于应用层服务，实际需要中，也包括领域服务，在基础设施里也有关于EMAIL的规则（API？）等。
[该贴被SpeedVan于2010-11-05 17:13修改过]

我谈一下我的看法。个人认为应用服务是离客户端最近的那个层，是从用户的角度去看的；而领域层服务更强调是逻辑的服务，是从业务逻辑去看的。这两者的区分是角度不同，并不矛盾，在小项目里是重叠的。而在大项目里，因为逻辑复杂所以用户的需求往往是多个逻辑服务组合起来才能完成，这里是分开的。