Service重在业务逻辑 目前我在开发中使用的Service，在设计上：
1、尽量无状态、单一职责，关联其它业务就注入其他业务用的Service。
2、例如UserService 只操作跟User相关的业务逻辑，BlogService只处理跟Blog相关的业务。
3、如果要查询这个用户的所有Blog，那需要通过BlogController去调用BlogService里getUserBlogList(userId)
4、如果综合查询分析和大业务 涉及N个表操作的，针对这个综合业务创建一个业务Service，注入所需关联的其他单个业务操作的Service，在综合业务Service里 调用处理。
5、这样单机应用 到分布式 微服务 都可以轻松扩展，有时候微服务了 controller层可以不要，使用Service注册到服务调度中心，远程调用即可，此时单一职责很重要。
6、其他。。。

@山东小木 感谢分享，请问你在生成的module中会编写代码吗？

比如User修改头像的需求，应该直接写在UserService中，还是在UserService.changHeadUrl()中调用User.changeHeadUrl() ?

在不考虑项目拆分为微服务的情况下，我个人是倾向于后者的，Controller只复杂接收参数与响应正确的逻辑。Service层组合各个Model的方法，如用户下单的业务，我可能倾向于在OrderService中组合Order,User的方法来完成业务逻辑。

修改不管是一个字段还是整体修改 都会在controller层获取请求的参数，然后发送给Service处理 service里具体如何处理 根据具体情况 如果是整个表单提交的model修改数据 最终调用的是model.update(),当然 我的BaseSericce里也封装了一个update(model)方法，用于处理最后的逻辑。
如果是单个字段的修改，一般获取的参数是model的ID+整个字段修改后的值，这样的情况可以执行sql或者使用Model
1、sql方式 Db.update("update table set attr=value where id=1"); 我是在baseService里封装了一个updateAttrById(id,attrName,attrValue)这样的方法
2、使用Model方式 new User().set("id",id).set("avatar",avatarUrl).update(); 类似这样的一波操作。
3、还有其他的 看具体情况