SSM框架構建多模組之業務拆分實踐
在如下這兩篇篇文章我都或多或少強調過業務分層方面的的方法和注意事項，感興趣的可以看看:
ofollow,noindex" target="_blank">系統設計和系統劃分有定律可循
之前是說，現在是做。以我個人部落格為例，我的部落格最初只是一個單體應用，但是我決定將其拆分為多個模組，總體來說，還是一個單體war。但是性質是不一樣的。
下面進入正題:
貼圖說明:
blog-parent是父工程
blog-common主要放置工具類和其他可以複用的第三方外掛或者是其他功能類
blog-entity 放置實體,通常是pojo也可以叫entity或者javabean
blog-dao 放置與資料庫互動的介面類，也就是mapper
blog-service 業務介面及其實現類
blog-web 前臺展示同時如果還開發安卓應用的話，直接提供介面
blog-generator 是程式碼生成器，主要應用於個人開發，提高效率用的
上述的依賴關係除了blog-generator之外，可以用思維導圖可以表示為如下所示:
不過這個結構似乎也不太合理，適用於目前而言，業務不是特別大，最好採用這種形式表示:
兩圖比較主要區別在於將blog-common放到blog-service中，因為blog-service是業務邏輯，通常業務邏輯是可以複用多個的，而像一些判斷或者是引用第三方外掛，通常都在業務邏輯裡具體實現後，而web模組中controlller直接呼叫即可，如果不放在blog-service中，就會出現一個問題，問題的主要凸顯就是業務邏輯複用性差，導致很多都在controller裡面下，也就是接口裡面寫，不利於複用，而且程式碼質量也會下降。
注意:
每個依賴記得都要maven install安裝到本地倉庫，否則會依賴不了，報錯。
專案github地址為:https://github.com/youcong1996/ChallengerV.git
專案結果圖如下所示:
前端模板主要採用的是layui，其實bootstrap也有很多這樣的，大家可以在網上找找。
其實我參考了github上的不少專案還有一些小夥伴們的部落格，其實還可以再細化分為如下(這裡我還是用思維導圖表示):
這樣做的好處，主要是考慮可擴充套件性，前面列舉的圖一和圖二可擴充套件性不是特別好，當然了，如果對於是一個人開發的話，直接單體應用即可，不用拆分，如果是兩到三個人，可以按照圖一和圖二來。當然了，圖一和圖二還有一個考慮就是可讀性，公司開發人員流動性比較強，特別是中小公司，總會有人走，也總會有人來，假如你是來的人，如果看到公司所有的程式碼全部在一個單體war上，而且有很多很多的com.xxxxx之類的，而且com.xxxxx下還有幾十個類，試問你會作什麼感想呢。
按照圖三的設計，以後的擴充套件可以是這樣：
隨著業務一步一步擴大，可以將blog-web拆分為六個war,這就可能用到微服務架構了。
最後小結:
業務的擴充套件是一步一步慢慢來的，絕非一開始直接就業務拆分和分散式，那都是扯淡。