先说下我最近做的一个小的人力资源管理系统。
数据库都是用 Dao访问的，负责返回一些 pojo,我的pojo 都是和数据库表或者视图对应的，Dao 负责把结果集包装为pojo。
Service层，我基本都是把Dao 层重新包装了一下，当然可能是我的系统比较简单哦，每个pojo对应一个Service，如EmployeeService,SalaryService等。
最后web 页面是通过 IOC方式获得Service的，任何得到一些Pojo进行处理...
现在呢，我想添加一些页面，主要都是查询数据库的功能，如 select count(*) from ...! 这样的话，我就要给 dao,service 接口添加方法，然后再实现，（我都是用接口+实现的方式开发的）。这样感觉比较麻烦，我想知道大家有没有一些比较好的建议能够把Service给简化一些，
这样做不麻烦，问题是你没有找到你继续做下去的指南针，这就是Evans DDD，你应该学习Evans DDD了。DDD会告诉你如何做Service，如何围绕Model展开详细业务。
多谢banq 指点，这几天仔细研究一下 DDD，
我以前也看了一些，不过不太理解！
学习DDD有什么好书可以推荐一下呢？
>学习DDD有什么好书可以推荐一下呢？
《领域驱动设计--软件核心复杂性应对之道》
【作 者】（美）Eric Evans [同作者作品] [作译者介绍]
【译 者】 陈大峰[同译者作品] 张泽鑫 等
【出 版 社】 清华大学出版社
个人觉得这是一个系统设计的问题，而不是编码实现技巧的问题。
一、对于Service，本人是这样认为的：Service是业务层，是整个系统的核心，不存在简单不简单的问题，你的Service提供多少种“服务”，你就必须暴露多少个接口，就如一个公司，每个业务都需要分类。Service层是不能抽象的，比如你想修改用户资料，DAO层可以抽象为“Update UserDO”，甚至进一步抽象为“Update Persistent Object”，但对于Service，“修改用户”可能表现为多种业务，例如：
1）修改用户状态（管理员做的事情）
2）修改用户信息（管理员和用户做的事情）
3）修改用户密码（用户做的事情）
对于这三种服务，其实都可以抽象为“Update UserDO”，为了简化Serivce，你可以设计一个服务接口：
public void update(UserDO userDO) throws ServiceExeption);
但，这样做，业务就无法分开了，如果需要进行权限控制，日志记录，系统根本无法做到。
结论：企图通过抽象和编程技巧简化Service是不合理的（当然，可以通过编程技巧，把多个操作的公共逻辑抽象成一个私有方法，这是值得提倡的）
二、针对DAO ，其实是可以简化的，其实DAO是与业务无关的，抽象上看，无非是“增删改查”，对于查询，可以提供一个接收“SQL”语句和参数的通用方法，对于查询数量，可以提供一个特定的方法，接收特定条件，再结合Java的泛型技术，完全可以设计出一个高度重用的DAO接口。