之前一直使用 http json 进行服务间通讯，最近改使用 dubbo 作为 rpc 框架，在设计服务接口的时候感觉有些疑问：
- 什么时候抛出异常,dubbo 使用手册上写的是
建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，以及语义更友好， 如果担心性能问题，在必要时，可以通过override掉异常类的fillInStackTrace()方法为空方法，使其不拷贝栈信息， 查询方法不建议抛出checked异常，否则调用方在查询时将过多的try...catch，并且不能进行有效处理， 服务提供方不应将DAO或SQL等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常。那么具体到一个add方法，操作成功还是失败，是返回int或者封装的结果集还是抛出异常，然后根据异常中定义的错误码和msg返回给消费者
-
方法的命名问题，一般建议是业务名称。但是对于简单的增删改查业务和 biz 经常会区分度不高，命名时是否要避免和 biz 相似？比我当前接口层设计业务的增加、修改、查询为: addXXX、changeXXX、fetchXXX，biz 层为:createXXX、modifyXXX,findXXX，dao 层为：insertXXX、updateXXX、queryXXX
-
关于接口返回值的问题，比如返回值为 UserName 和 UseId 是应该返回 UserDTO 呢，还是返回 List<Map>。有着怎么的最佳实践。
-
关于 dubbo 文档的一个疑问,引用中的下划线部分怎么理解，比如 AccountServicel.login(username,passwd)方法实现中 username、passwd 是需要判断为 null，还是有一个共同的约束就好：
不要只是因为是 Dubbo 调用，而把调用 Try-Catch 起来。Try-Catch 应该加上合适的回滚边界上。
对于输入参数的校验逻辑在 Provider 端要有。如有性能上的考虑，服务实现者可以考虑在 API 包上加上服务 Stub 类来完成检验。
目前困扰比较大的主要是第一个问题。大家有经验的指导指导。附 dubbo 中文指南
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于