微服务接口设计的思路---java接口约束的现状思考

此篇文章在未探究thrift等跨语言服务调用下编写

接口在我的概念里不仅仅是对外暴露的一种手段，其实也是一种约束。微服务中倡导的去中心化过程中，接口的约束越来越重。比如有以下的接口：

public interface UserService{
    
    /**
     * 根据名称生成一个用户
     */
    User createUser(String name);
}

后面随着需求的变更，开始变为了根据用户名称和年龄生成一个用户,为了兼容之前的接口，那么新建一个方法即可，具体如下

public interface UserService{
    
    /**
     * 根据名称生成一个用户
     */
    User createUser(String name);
    
    /**
     * 根据用户名称和年龄生成一个用户
     */
    User createUser(String name, Integer age);
}

试想，如果再加入用户邮箱、用户地址、用户手机号，按照排列组合的全排列的方式，那么会有5! = 5 * 4 * 3 * 2 * 1 = 120个方法。岂不是boom

那么有以下设计接口的方式，将封装成一个对象

public interface UserService{
    
    /**
     * 根据用户生成一个用户
     */
    User createUser(User model);
}

仿佛世界和平了

但是这样在每一次客户端调用的时候，判断用户是否创建成功都会有如下的代码

User result = userService.