Dubbo 服务接口设计疑问

之前一直使用 http json 进行服务间通讯，最近改使用 dubbo 作为 rpc 框架，在设计服务接口的时候感觉有些疑问：

1. 什么时候抛出异常,dubbo 使用手册上写的是

建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，以及语义更友好， 如果担心性能问题，在必要时，可以通过override掉异常类的fillInStackTrace()方法为空方法，使其不拷贝栈信息， 查询方法不建议抛出checked异常，否则调用方在查询时将过多的try...catch，并且不能进行有效处理， 服务提供方不应将DAO或SQL等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常。

1. 方法的命名问题，一般建议是业务名称。但是对于简单的增删改查业务和 biz 经常会区分度不高，命名时是否要避免和 biz 相似？比我当前接口层设计业务的增加、修改、查询为: addXXX、changeXXX、fetchXXX，biz 层为:createXXX、modifyXXX,findXXX，dao 层为：insertXXX、updateXXX、queryXXX

2. 关于接口返回值的问题，比如返回值为 UserName 和 UseId 是应该返回 UserDTO 呢，还是返回 List<Map>。有着怎么的最佳实践。

3. 关于 dubbo 文档的一个疑问,引用中的下划线部分怎么理解，比如 AccountServicel.login(username,passwd)方法实现中 username、passwd 是需要判断为 null，还是有一个共同的约束就好：

不要只是因为是 Dubbo 调用，而把调用 Try-Catch 起来。Try-Catch 应该加上合适的回滚边界上。
对于输入参数的校验逻辑在 Provider 端要有。如有性能上的考虑，服务实现者可以考虑在 API 包上加上服务 Stub 类来完成检验。

目前困扰比较大的主要是第一个问题。大家有经验的指导指导。附 dubbo 中文指南