小設計，大作用——談談防腐層的妙用
前言
最近在看領域驅動模型DDD相關的東西，由于沒有實際的項目支撐，所以大都是停留在一些理論層面。但是我發現這里面的一些設計思想還是非常有實用價值的，可以直接應用于你目前的項目中，今天我就來談談防腐層的妙用。
一個簡單的例子
大家在做項目中是否有過這樣的經歷，你的項目中需要調用一個外部服務接口，而這個外部服務接口需要在你的項目中的不同地方被多次使用，比如在公司項目中就出現調用下面獲取用戶詳細信息的外部的接口多達10幾次。
SessionUser getUserDetail(String username)SessionUser getUserDetail(String username)一旦這個外部接口發生變化，那么是不是意味著我就要修改這幾十處的地方，簡直頭大。
那我們是不是可以對外部接口做一層適配封裝，隔離這種可能地、不可控的變化。因此在我們的manager層中添加了一個UserManager的類，如下所示：
@Component
public class UserManager() {
@Autowired
private UserApi remoteUserApi;
public UserDTO getUserDetail(String username) {
SessionUser sessionUser = remoteUserApi.getUserDetail(username);
UserDTO user = convertUser(sessionUser);
return user;
}
}@Component
public class UserManager() {
@Autowired
private UserApi remoteUserApi;
public UserDTO getUserDetail(String username) {
SessionUser sessionUser = remoteUserApi.getUserDetail(username);
UserDTO user = convertUser(sessionUser);
return user;
}
}我們讓系統中的業務層從原來直接調用remoteUserApi.getUserDetail(String username)改為調用UserManager#getUserDetail()，這樣哪怕有一天外部接口的返回內容、方法名發生變化，我們也只需要修改一下這一個地方，而無需修改上層調用的十幾處地方。
另外，我們還可以再這一層加入更多的功能，比如參數校驗，日志打印等等，如下代碼所示：
@Component
public class UserManager() {
@Autowired
private UserApi remoteUserApi;
public List<UserDTO> getUserDetail(String username) {
// 參數校驗
if(StrUtils.isBlank(username)) {
throw new UserException("用戶名不能為空")；
}
long t1 = System.currentTimeMillis();
SessionUser sessionUser = remoteUserApi.getUserDetail(username);
long t2 = System.currentTimeMillis();
// 打印日志，方便甩鍋
if(t2 - t1 > 3000L) {
log.warn("調用外部接口耗時過長，cost:[{}]ms", t2 - t1);
}
UserDTO user = convertUser(sessionUser);
return user;
}
}@Component
public class UserManager() {
@Autowired
private UserApi remoteUserApi;
public List<UserDTO> getUserDetail(String username) {
// 參數校驗
if(StrUtils.isBlank(username)) {
throw new UserException("用戶名不能為空")；
}
long t1 = System.currentTimeMillis();
SessionUser sessionUser = remoteUserApi.getUserDetail(username);
long t2 = System.currentTimeMillis();
// 打印日志，方便甩鍋
if(t2 - t1 > 3000L) {
log.warn("調用外部接口耗時過長，cost:[{}]ms", t2 - t1);
}
UserDTO user = convertUser(sessionUser);
return user;
}
}我們可以加上額外的參數驗證，打印調用外部接口的耗時，有理由“甩鍋”。
防腐層介紹
通過上面一個簡單的例子，你是不是對防腐層有了一個初步的認識。通俗的說，我們認為外部系統、接口中間件等都是腐爛的，不可控的，我們需要添加一層去做隔離和防腐，被叫做防腐層。
大多數應用程序依賴于其他系統的某些數據或功能。例如，舊版應用程序遷移到新式系統時，可能仍需要現有的舊的資源。新功能必須能夠調用舊系統。逐步遷移尤其如此，隨著時間推移，較大型應用程序的不同功能遷移到新式系統中。
這些舊系統通常會出現質量問題，如復雜的數據架構或過時的 API。舊系統使用的功能和技術可能與新式系統中的功能和技術有很大差異。若要與舊系統進行互操作，新應用程序可能需要支持過時的基礎結構、協議、數據模型、API、或其他不會引入新式應用程序的功能。不僅僅是舊系統，不受開發團隊控制的任何外部系統(第三方系統)都可能出現類似的問題，因此引入防腐層去做隔離解決。
圖片
如上圖所示，子系統 A 通過防腐層調用子系統 B。子系統 A 與防腐層之間的通信始終使用子系統 A 的數據模型和體系結構。防腐層向子系統 B 發出的調用符合該B子系統的數據模型或方法。防腐層包含在兩個系統之間轉換所必需的所有邏輯。該層可作為應用程序內的組件或作為獨立服務實現。
總結
說了那么多，這是不是和設計模式中的適配器模式很像，實際上防腐層也叫適配層。當然寫防腐層也是有代價的。最大的代價就是有「額外的開發成本」。所以如果你的上下游比較少，且比較穩定，其實是可以不用防腐層的。但是在大型團隊，付出這些額外的開發成本是有價值的，因為大型團隊的上下游關系非常復雜，他們可能不是在一個團隊，也有可能經常進行迭代升級，通過我自己的經驗來看，接口變化是經常會發生的。
