設計討論：依賴倒置，與 “I'll call you”

問題來自于我和同事在一個跨系統交互設計上的分歧。

同事的設計，基本上是這樣的：

這種設計很常見，其基本思路就是：服務端接口需要什么數據，客戶端就傳入什么數據。這種設計的優點在于簡單：開發簡單，交互簡單。但是它的缺點也很明顯：擴展性低。一旦服務端對某個業務中的業務-數據依賴關心進行了修改，則客戶端很可能也要跟著修改。例如，如果系統B中，完成業務B1需要的數據不再是D1而是D3，則不光系統B要改，系統A也要改。如果還有系統C/D/E/F也調用了這個接口，那么這些系統都面臨著修改代碼的風險。

實際上，不僅僅是系統間的服務，在系統內部服務的設計上，這種思路也很常見。我曾經見過一個用作金額計算的類。它的計算公式是a+b/c-d^e，而它對外暴露的方法居然就是public BigDecimal calculate(BigDecimal a, BigDecimal b, BigDecimal c, BigDecimal d, BigDecimal e)。當公式需要擴展為a+b/c-d^e-f時，其中的麻煩可想而知。

造成這種風險、麻煩的原因就在于：這個設計不僅簡單的實現了客戶端對服務端的業務依賴，而且將服務端內部的控制依賴也暴露、延伸到了客戶端。

客戶端對服務端的依賴，是一種業務上的“正向”依賴。沒有服務端提供的服務，客戶端的業務也無法正常的進行下去。

但是，我們在做設計的時候，不應當簡單的臨摹業務流程。業務流程從A到B，系統設計就畫兩個方框+一個箭頭；這是在為現在的自己偷懶。更不應當把業務流程中的依賴關系過度的延伸出去；這簡直是在為三個月后的自己挖墳。

對這一個系統的設計，我的觀點就是：系統B把業務-數據間的依賴關系全部收到自己的系統中去。如下圖。

即，客戶端在調用時，提供一個數據主鍵。服務端根據自己的業務需要，按主鍵去查詢出所需的數據。

這樣做的缺點是復雜。代碼會復雜，交互也更復雜。由于多了一次交互，性能上會有下降。另外在分布式事務方面還有一點小隱患。

但是這樣的優點，恰恰就是易于擴展。只要新業務所需數據仍然落在數據集合D內，那么系統A無需任何改動。

帶來這個優點的，就是依賴倒置。雖然在業務上，是客戶端依賴于服務端的功能；但是在設計上，是服務端依賴于客戶端的數據。并且，這種依賴只是簡單的數據依賴。這也是所謂的“好萊塢法則”：Don't call me, I'll call you! 

實際上，同事的設計和我的設計，在我們的系統中都已經有了實踐。到目前為止的結果，是按同事的思路設計的另一個系統服務已經經過了二次改造，歸入我的思路中了。而按我的思路設計的另一個系統服務，目前在做性能上的優化。

遺憾的是，我沒有說服他。他仍然堅持己見，只是在客戶端調用接口時，將數據集合D一次性提交到服務端。

這種思路算一個折中。但是，如果服務端所需數據集超過了數據D呢？按他的方案，客戶端仍然需要修改；按我的方案，在客戶端沒有開通對應的查詢接口時也需要修改。只不過，客戶端是我負責的系統（也許這也是我一直跟他爭執的原因之一吧），而這個系統中，已經規劃了“每個資源都應有查詢服務”。

附，分布式事務上的一點小隱患在于：如果在客戶端調用服務端的那個事務中，主鍵key所對應的數據有部分還未提交，那么，通過查詢接口是無法查詢到這部分數據的。彌補措施是在服務接口中把這一部分數據傳過來，作為“優先”配置或數據，覆蓋查詢接口中查到的結果。