java~接口的共享实体使用Map后更灵活

微服务时代的实体设计

在一个微服务时代，一个实体参数或者返回值，它可能是多服务之前共享的，而这个重复的实体你需要拷贝多份，这是违背DRP原则的，所以我们需要找一种更友好的方式来代替它，它就是Map，我们把实体的属性都映射成Map这种k、v的形式即可解耦！

B服务不需要处理A服务的实体

如果只是接受实体，然后把它传递给C服务，这时，你直接把它设计成Map即可

public class ADto:HashMap<String,Object>{}

B服务需要加工，过滤A服务的实体

如果B服务拿到A服务的实体后，需要对某些字段进行处理，那我们需要把这些字段抽象出来，把它的get方法公开，在程序的其它地方使用，而不需要把所有字段都复制过来，这也是解耦的一种体现！

/**
 * A计算模板.
 */
public class ATemplate extends HashMap<String, Object> {

  public Boolean getAllowBuildAccount() {
    return Boolean.valueOf(this.get("allowBuildAccount").toString());
  }


  public Boolean getAllowMakeAccount() {
    return Boolean.valueOf(this.get("allowMakeAccount").toString());
  }
}

在程序里，你可以使用这两个公司的方法

 List<ValidateResult> validateResultsList =
        accountsValidate(currentClientAccount, false, o -> o.getAllowMakeAccount()); //使用predicate里过滤它的字段

思路模型

graph TD b(a服务)-->a(HashMap) a-->c(b服务) a1(HashMap)-->Entity1 a1-->Entity2

个人认为：这种设计非常巧妙，当然会有一些装箱和拆箱的操作，但与程序扩展性相比，简直可以忽略！