微服務時代的實體設計

在一個微服務時代，一個實體引數或者返回值，它可能是多服務之前共享的，而這個重複的實體你需要拷貝多份，這是違背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裡過濾它的欄位

思路模型

個人認為：這種設計非常巧妙，當然會有一些裝箱和拆箱的操作，但與程式擴充套件性相比，簡直可以忽略！