系統模塊劃分設計的思考
前言
首先明確一下，這裏所說的系統模塊劃分，是針對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。兩者的組合方式有很多，取決於使用者的需要，以後有機會寫一篇相關的博客。不過，我希望大家記住 面向接口編程的原則。
願與諸君共進步。