系統模塊劃分設計的思考前言首先明確一下，這裡所說的系統模塊劃分，是針對client，service，common這樣的技術劃分，而不是針對具體業務的模塊劃分。避免由於歧義，造成你的時間浪費。直接原因公司內部某技術團隊，在引用我們系統的client包時，啟動失敗。失敗原因是由於client下 ...

系統模塊劃分設計的思考

前言

首先明確一下，這裡所說的系統模塊劃分，是針對client，service，common這樣的技術劃分，而不是針對具體業務的模塊劃分。避免由於歧義，造成你的時間浪費。

公司內部某技術團隊，在引用我們系統的client包時，啟動失敗。
失敗原因是由於client下有一個cache相關的依賴，其註入失敗導致的。

然後，就發出了這樣一個疑問：我只是希望使用一個hsf介面，為什麼還要引入諸如緩存，web處理工具等不相關的東西。

這也就自然地引出了前輩對我的一句教導：對外的client需要儘可能地輕便。

很明顯，我們原有的client太重了，包含了對外的RPC介面，相關模型（如xxxDTO），工具包等等。

可能有人就要提出，直接RPC+模型一個包，其它內容一個包不就OK了嘛？

問題真的就這麼簡單嘛？

其實出現上述問題，是因為在系統設計之初，並沒有深入思考client包的定位，以及日後可能遇到的情況。

這也就導致了今天這樣的局面，所幸目前的外部引用並不多，更多是內部引用。及時調整，推廣新的依賴，與相關規範為時不晚。

先說說我以前的模塊拆分。最早的拆分是每個業務模塊主要拆分為：

這種拆分方式，是我早期從一份微服務教程中看到的。優點是簡單明瞭，調用方可選擇性地選擇需要的模塊引入。

至於一些通用的組件，如統一返回格式（如ServerResponse，RtObject），則放在了最早的核心（功能核心，但內容很少）模塊上。

後來，認為這樣並不合適，不應該將通用組件放在一個業務模塊上。所以建立了一個base模塊，用來將通用的組件，如工具，統一返回格式等都放入其中。

另外，將每個服務都有的xxx-common模塊給取消了。將其中的模型，放入了xxx-client，畢竟是外部調用需要的。將其中的工具，根據需要進行拆分：

上述這個方案，也就是我在負責某物聯網項目時採用的最終模塊劃分方式。

在當時的業務下，該方案的優點是模塊清晰，較為簡潔，並且儘可能滿足了迪米特原則（可以參考《阿裡Java開發手冊相關實踐》）。缺點則是需要一定的技術水平，對組件的功能域認識清晰。並且需要有一定的設計思考與能力（如上述工具拆分的第三點-xxx-client，明白為什麼這是設計缺陷導致，並能夠解決）。

那麼，既然上述的方案挺不錯的，為什麼不復用到現在的項目呢？

因為業務變了，導致應用場景變了。而這也帶來了新的問題，新的考慮角度。

原先的物聯網業務規模並不大，所以依賴也較為簡單，也並不需要進行依賴的封裝等，所以針對主要是client的內/外這一維度考慮的。

但是現有的業務場景，由於規模較大，模塊依賴層級較多，導致上層模塊引入過多的依賴。如有一個緩存模塊，依賴tair-starter（一個封裝的key-value的存儲），然後日誌模塊依賴該緩存模塊（進行性能優化），緊接著日誌模塊作為一個通用模塊，被放入了common模塊中。依賴鏈路如下：

調用方 -> common模塊 -> 日誌模塊 -> 緩存模塊 -> tair-starter依賴

但是有的調用方表示，根本就不需要日誌模塊，卻引入了tair-starter這一重依賴（starter作為封裝，都比較重），甚至由於tair-starter的內部依賴與自身原有依賴衝突，得去排查依賴，進行exclude。
但是同時，也有的調用方，系統通過rich客戶端，達到性能優化等目標。

所以，現有的業務場景除了需要考慮client的內/外這一維度，還需要考慮client的pool/rich這一維度。

可能有的小伙伴，看到這裡有點暈乎乎的，這兩個維度考量的核心在哪裡？

內/外，考慮的是按照內外這條線，儘量將client設計得簡潔，避免給調用方引入無用依賴。

而pool/rich，考慮的是性能，用戶的使用成本（是否開箱即用）等。

最終的解決方案是對外提供3+n

xxx-client（1個）：所有外部系統引用都需要的內容，如統一返回格式等。
xxx-yyy-client（n個）：對具體業務依賴的引用，進行了二次拆分。如xxx-order-client（這裡是用訂單提花那你一下，大家理解意思就OK）。
xxx-pool-client（1個）：系統引用所需要的基本依賴，如Lindorm的依賴等。
xxx-rich-client（1個）：系統引用所需要的依賴與對應starter，如一些自定義的自動裝載starter（不需要用戶進行配置）。

這個方案，換個思路，理解也簡單。
我們提供相關的能力，具體如何選擇，交給調用方決定。

其實，討論中還提到了BOM方案（通過DependentManagement進行jar包版本管理）。不過分析後，我們認為BOM方案更適合那些依賴集比較穩定的client，如一些中間件。而我們目前的業務系統，還在快速發展，所以並不適用。

簡單來說，直接從用戶需求考慮（這裡的用戶就是調用方）：

外部依賴：
- 額外引入的依賴儘可能地少，最好只引入二方依賴（我們提供的jar），不引入第三方依賴。
- 引入的二方依賴不“夾帶”私貨（如二方jar引入了一堆大第三方依賴）。
自動配置：
- 可以傻瓜式使用。如引入對應的starter依賴，就可以自動裝配對應預設配置。
- 也可以自定義配置。用戶可以在自定義配置，並不用引入無效的配置（因為starter經常引入不需要的依賴）。
性能：
- 可以通過starter，提供一定的封裝，保證一定的性能（如介面緩存，請求合併等）。
- 可以自定義實現基礎功能。因為有些人並不放心功能封裝（雖然只是少數，但是穩定性前輩提出的）。

這裡補充一點，我對討論中一個問題的回答，這裡提一下。

有人提到工具類，應該如何劃分。因為有的工具類，是不依賴於服務狀態的，如CookieUtil進行Cookie處理。有的工具類，是依賴於服務狀態的，如RedisUtil包含RedisPool狀態，直連Redis，處理Redis請求與響應。

其實這裡有兩個細節：

工具應該按照上面的方式進行劃分為兩種。單一模塊系統，不依賴服務狀態的工具往往置於util包，依賴服務狀態的工具往往置於common包中。這裡還有一個明顯的區分點：前者的方法可以設為static，而後者並不能（因為依賴於new出來的狀態）。
依賴於狀態的工具類，其實是一種拆分不完全的體現。如RedisUtil，可以拆分為連接狀態管理的RedisPool與請求響應處理的RedisUitl。兩者的組合方式有很多，取決於使用者的需要，以後有機會寫一篇相關的博客。不過，我希望大家記住面向介面編程的原則。

願與諸君共進步。