項目模塊間交互的一個設計思路及其延伸

 

 

 

 

1.背景

　　某API項目，項目自然地按業務分爲了避免同的包，那麼每一個包都獨立處理本身的業務邏輯，獨立接管數據源，獨立地向外部提供數據，彼此基本互不通訊。

　　不過，隨着需求的增多和業務的堆積，項目的複雜度愈來愈大，可是每一個獨立模塊卻又不足以獨立出去成爲一個單獨的項目，而模塊間又因業務須要開始發生交互的時候，問題來了。　

 

2.問題描述

　　因爲模塊間的數據交互，按照Spring的套路，是能夠直接把容器接管的對象注入到你須要的地方去的，那麼一旦你開始問其餘模塊要數據，開始要命了。如上圖，若是模塊3問模塊2和模塊4要數據，理論上來講，他是否是能夠隨意注入這兩個模塊的各類服務呢？

　　答案是確定的。這個時候你會發現一個問題，因爲原本在一個模塊內某個數據源可能通過多重必要的封裝再提供接口數據的，可是其餘模塊他並不知道這一點。因而他極有可能注入數據源在封裝的過程當中各個階段的服務類，也有可能直接注入了最底層的數據接口，他再去作本身的邏輯處理去本身封裝一遍。這樣，漫天飛舞的入侵完成了，這個地方飛滿了各類各類的花蝴蝶，簡直眼花繚亂，一片失去控制的景象。

 

3.解決思路

　　這個時候筆者想到是否能夠把某個模塊的各類數據服務彙集到一個服務中去呢，對外部（其餘模塊）來講，約定好只容許調用我這個公共的服務接口，我對外部屏蔽掉全部邏輯，你外部也不用關心個人數據怎麼來的，你只要問我這個接口要數據便可。如上圖所示，

到此問題基本能夠解決，優缺點也在圖中描述了。

 

4.深刻

　　接着，筆者發現其實這個設計思路，相似於門面模式，或者說就是門面模式。網絡上找來了門面模式的意圖：　

• Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
• 對子系統中的一組接口提供了一個統一的接口。門面定義了更高層次的接口，使子系統更容易使用。
• Wrap a complicated subsystem with a simpler interface.
• 以簡單的接口包裝複雜的子系統

　　能夠看到，筆者文章中所說的能夠被視爲是門面模式的一個應用場景，雖然不是系統級別的交互而只是模塊之間的交互，可是筆者相信這樣去設計至少在接口的易用性和模塊間的解耦程度上，是能夠作到有所提升的。至此，門面模式get。

　　維基百科傳送門：https://en.wikipedia.org/wiki/Facade_pattern