view-->controller-->service-->dao-->entity
1.controller层
（1）职责：负责协调view层与service层，具体而言就是获取、过滤view层的输入，调用相应的service逻辑处理并根据其返回结果选择不同的view进行显示。
（2）依赖性：向下依赖service，向上依赖容器或框架
2.service层
（1）职责：负责向controller提供业务逻辑处理接口，事务安全的调用dao层完成业务逻辑处理。
（2）依赖：组合或继承dao（下面会解释）或向下依赖dao，向上依赖容器或框架。
3.dao层
（1）职责：负责对应实体的持久化工作，包括CRUD等。
（2）依赖：向下依赖PO或entity，向上依赖容器或框架
上面说到service会组合或继承dao，我相信有人会觉得疑惑或质疑。我以我个人的认知来谈谈这个问题。首先，我们不能排除那些微型的基于数据库CRUD的JEEApp的存在，实际上留言板、BBS等都具有该特点，在这种系统中，service层对controller提供的业务逻辑接口至少会有CRUD方法吧？而且是“纯粹”的CRUD，例如添加一条留言，这个行为无论对于service还是dao来说，都是一样的，其方法签名甚至连名字都可以一样，那么，我们是否可以让service具有CRUD的能力呢？不仅如此，我们是否应该无需手动编写任何的CRUD代码呢？（因为这些代码完全可以让反射帮你搞定）。那么，service层到底应该手动编写什么代码呢？从上面说到的职责来看，有两个理由，一个是具有事务性，一个是复杂性，这里说的复杂性是对于超过单个dao方法能力而言。例如前面谈到的添加一条留言，如果添加留言需要某些前置条件，例如保证添加者是登陆状态的，那么这时候dao的create方法就没办法满足要求了，这时候service的create和dao的create方法处理逻辑完全不同，因此需要手动编写service的create方法了，也许编写如下：
public String create(MessageVO message,HttpServletSession session){
String error = null;
if (session.getAttribute(message.getAuthor()) == null){
error = "您还没有登录，请先登录才能发表留言";
}else{
error = this.dao.create(message);
}
return error;
}
但是，如果没有这种需求呢？如果仅仅是发表一下留言而无需登陆呢？我想，这这时候代码应该如下：
public String create(Message message){
return this.dao.create(message);
}
我们发现这时候service里的create方法做的仅仅是调用一下dao的create方法而已，除此之外没有任何额外的动作，那么，想象一下，如果一个系统的service层，这样的方法竟然占了大部分，我想，没有人愿意承受这样无趣的代码编写工作吧？这种问题其实完全可以通过组合dao或者继承dao来解决。这时候，service层依然存在，但是某些无趣的代码就无需开发者手动编写了，当然，前提条件是“无趣的代码”，这里即和dao完全一样的代码，再当然，这一切都基于需求，需求决定了是否能够这样做，上面的例子也已经足够说明问题了，不是吗？
另外，对于DomainModel，我个人有这样一个想法，DomainModel不需要也不必要一一对应一个Java Class，它是对现实世界某个领域的建模，而实现这种模型可以通过多个类的协作或组合来达到目的。Java现在的做法就是Service+DAO+PO的方式。我个人是这么理解的这三部分与DomainObject的关系的，Service包含了DomainObject的DomainLogic，DAO解决了DomainObject的持久化逻辑，PO封装了DomainObject的属性。这三者共同协作完成了对Domain建模（模拟？反映？）
而对于ROR里一个domain既包含了持久化行为，又包含了逻辑行为，本身还是属性数据载体的做法，本人水平有限，不敢苟同。它宣称这样更加OO，可是OO里另外一条重要的原则“保持类的职责单一”，却在这里被违背了，在我认为，持久化、商业（领域）逻辑、数据载体（对外提供setter和getter访问）都算一种职责，那么这里就已经包含了三中职责了。
本人是菜鸟，欢迎拍砖。