服务接口设计原则

        好的服务接口设计，并非只是纯粹的接口服务化。

1、接口类型

         简单数据查询接口：action、facade、dao；

        带业务逻辑的数据查询接口：action、facade、biz、dao；

        简单的数据写入接口：action、facade、dao；

        带业务逻辑的数据写入接口：action、facade、biz、dao ；

        同步接口；

        异步接口。

2、接口粒度

        服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将面临分布式事务问题。同时可以减少系统间的网络交互。

        服务接口建议以业务场景为单位划分，并对相近的业务做抽象，防止接口数量爆炸。

        不建议使用过于抽象的通用接口，如：Mapquery(Map)，这样的接口没有明确语义，会给后期维护带来不便。

3、接口版本

        每个接口都应定义版本号，为后续不兼容升级提供可能。

4、接口兼容性

        服务接口增加方法，或服务模型增加字段，可向后兼容；删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需通过变更版本号升级。

5、异常处理

        建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多信息，以及语义更友好。

        如果担心性能问题，在必要时，可以通过override掉异常类的fillInStackTrace()方法为空方法，使其不拷贝栈信息。

        查询方法不建议抛出checked异常，否则调用方在查询时将过多的try...catch，并且不能进行有效处理。

        服务提供方不应将DAO或SQL等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常。

6、必要的接口输入参数校验