在如下這兩篇篇文章我都或多或少強調過業務分層方面的的方法和注意事項，感興趣的可以看看:
之前是說，現在是做。以我個人博客為例，我的博客最初只是一個單體應用，但是我決定將其拆分為多個模塊，總體來說，還是一個單體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,這就可能用到微服務架構了。
最后小結:
業務的擴展是一步一步慢慢來的，絕非一開始直接就業務拆分和分布式，那都是扯淡。