系統模組劃分設計的思考
前言
首先明確一下，這裡所說的系統模組劃分，是針對client，service，common這樣的技術劃分，而不是針對具體業務的模組劃分。避免由於歧義，造成你的時間浪費。
直接原因
公司內部某技術團隊，在引用我們系統的client包時，啟動失敗。
失敗原因是由於client下有一個cache相關的依賴，其注入失敗導致的。
然後，就發出了這樣一個疑問：我只是希望使用一個hsf介面，為什麼還要引入諸如快取，web處理工具等不相關的東西。
這也就自然地引出了前輩對我的一句教導：對外的client需要儘可能地輕便。
很明顯，我們原有的client太重了，包含了對外的RPC介面，相關模型（如xxxDTO），工具包等等。
可能有人就要提出，直接RPC+模型一個包，其它內容一個包不就OK了嘛？
問題真的就這麼簡單嘛？
根本原因
其實出現上述問題，是因為在系統設計之初，並沒有深入思考client包的定位，以及日後可能遇到的情況。
這也就導致了今天這樣的局面，所幸目前的外部引用並不多，更多是內部引用。及時調整，推廣新的依賴，與相關規範為時不晚。
常見模組拆分
先說說我以前的模組拆分。最早的拆分是每個業務模組主要拆分為：
- xxx-service：具體業務實現模組。
- xxx-client：對外提供的RPC介面模組。
- xxx-common：對外的工具，以及模型。
這種拆分方式，是我早期從一份微服務教程中看到的。優點是簡單明瞭，呼叫方可選擇性地選擇需要的模組引入。
至於一些通用的元件，如統一返回格式（如ServerResponse，RtObject），則放在了最早的核心（功能核心，但內容很少）模組上。
後來，認為這樣並不合適，不應該將通用元件放在一個業務模組上。所以建立了一個base模組，用來將通用的元件，如工具，統一返回格式等都放入其中。
另外，將每個服務都有的xxx-common模組給取消了。將其中的模型，放入了xxx-client，畢竟是外部呼叫需要的。將其中的工具，根據需要進行拆分：
- base：多個服務都會使用的。
- xxx-service：只有這個服務本身使用
- 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。兩者的組合方式有很多，取決於使用者的需要，以後有機會寫一篇相關的部落格。不過，我希望大家記住 面向介面程式設計的原則。
願與諸君共進步。